Własne API dla ERP w MŚP: kiedy się opłaca i jak nie zrobić bezpiecznej dziury

Prędzej czy później ktoś zapyta: „a dacie nam się podpiąć?". Sklep, którym handluje kluczowy klient. Partner B2B, który chce widzieć nasze stany magazynowe co 15 minut. Kurier, który prosi o webhooka po wysyłce. Ta chwila jest momentem decyzji — albo wystawiasz własne API nad ERP, albo dopisujesz kolejną paczkę roboty, którą ktoś w firmie będzie łatał w Excelu do końca życia.

Ten tekst jest o tym, kiedy w MŚP naprawdę warto wystawić API nad Comarch Optimą, enova365, Subiektem albo Dynamics AX-em, jak zaprojektować to sensownie i — co ważniejsze — jak nie zrobić z tego drzwi wejściowych dla całego internetu.

Kiedy warto wystawić API — a kiedy nie

Nie każdy problem, który wygląda jak „potrzebujemy API", faktycznie API rozwiązuje. Zanim wydasz choć złotówkę, warto uczciwie odpowiedzieć na trzy pytania.

• Ile razy w tygodniu ta sama informacja jest ręcznie przepisywana lub wysyłana Excelem? Jeśli mniej niż 5 razy — API prawdopodobnie się nie zwróci. Automatyzacja dla samej zabawy to kosztowna zabawka.
• Czy dane, o które ktoś prosi, są aktualne w ERP w tym samym momencie, w którym są potrzebne odbiorcy? Jeśli stany magazynowe mają być „na teraz", a Ty odświeżasz je do klienta raz dziennie CSV-em, to problem nie zniknie bez API — zniknie razem z klientem.
• Czy w perspektywie 12 miesięcy pojawi się drugi, trzeci, czwarty integrator z podobną prośbą? Jeden partner to często jednorazowa rura Excel-mail. Trzech partnerów z identyczną prośbą — to sygnał, że API zwróci się bez dyskusji.

W praktyce widzimy trzy sytuacje, w których wystawienie własnego API jest oczywistą decyzją: partnerzy B2B, którzy odpytują o stany i ceny; własny sklep internetowy albo Allegro, w którym trzeba synchronizować zamówienia dwustronnie; oraz aplikacje mobilne dla handlowców w terenie, które muszą działać także wtedy, gdy w biurze nikogo nie ma. W każdej z tych sytuacji ręczna alternatywa — CSV o północy, przeklejki, „za chwilę odezwę się mailem" — kosztuje więcej niż projekt, po dwóch–trzech kwartałach mierzalnie.

Sytuacje, w których API to strzelanie do wróbla z armaty: pojedynczy raport miesięczny do księgowej biura zewnętrznego (wystarczy eksport), jednorazowa migracja danych do nowego systemu (skrypt ETL, nie API), albo integracja typu „zbieramy leady z formularza na stronę" (wystarczy webhook + Zapier/Make).

35 osób, 3 partnerów, 6 godzin tygodniowo w handlu

U jednego z naszych klientów — 35-osobowego dystrybutora części przemysłowych z Polski centralnej — problem wyglądał tak: trzej kluczowi klienci B2B (spółki produkcyjne z 200–500 osobami) codziennie kontaktowali się z ich handlem z pytaniem „czy jest jeszcze X sztuk", „kiedy dojdzie następna dostawa", „jaka jest cena netto dla nas przy 500 sztukach". Handlowcy odpisywali po zajrzeniu do Comarch Optimy. Odpowiedź trafiała mailem albo telefonem, klient wpisywał ją do swojego arkusza, a za 4 godziny — kiedy stan już się zmienił — dzwonił jeszcze raz.

Wersja skrócona: 6 godzin tygodniowo dwóch handlowców tracone na pytanie i odpowiedź o dane, które komputer mógłby oddać sam, w ułamku sekundy.

Wystawiliśmy nad Optimą warstwę API w .NET-cie z czterema endpointami: stany magazynowe (per SKU, per magazyn), aktualny cennik indywidualny (per kontrahent), historia zamówień danego kontrahenta i potwierdzenie nowego zamówienia. Uwierzytelnianie na kluczu API na partnera, ograniczenie tempa 60 zapytań na minutę, wszystkie zapytania logowane. Baza Optimy — nietknięta bezpośrednio; middleware pobiera dane cache'em odświeżanym co 60 sekund, co eliminuje ryzyko obciążenia produkcyjnej instancji.

Efekt po dwóch miesiącach: partnerzy sami odpytują API co 15 minut, handlowcy odzyskali te 6 godzin tygodniowo i przekierowali je na pozyskiwanie nowych klientów. Klient „utyskujący", który poprzednio dzwonił kilkukrotnie dziennie, przeniósł 40% zamówień z jednorazowych na cykliczne (bo wreszcie mógł zaufać danym). Zwrot z inwestycji — cztery miesiące. Projekt kosztował mniej niż półroczna pensja jednego handlowca.

Nie wystawiaj bazy ERP-a bezpośrednio

To najczęstszy błąd, który widzimy u firm, które próbowały same. Ktoś włączył w SQL Serverze dostęp z zewnątrz, założył konto „api_user", dał select na wszystkim i „proszę bardzo, macie dostęp". Trzy tygodnie później — problem wydajnościowy na produkcji, bo partner puścił zapytanie skanujące 400 tysięcy pozycji dokumentów w środku dnia. Sześć tygodni później — konto api_user wypłynęło razem z hasłem w mailu, który ktoś przekazał podwykonawcy, a ten swojemu koledze.

Reguła jest krótka: między ERP-em a światem zewnętrznym musi być warstwa pośrednia. W typowym MŚP wystarczy prosta usługa .NET (albo Node.js, wybór technologii jest tu wtórny), która:

• Trzyma logikę uwierzytelniania (klucz, OAuth albo JWT — nie bezpośrednie hasła do bazy).
• Cache'uje najczęstsze zapytania (stany magazynowe, cennik) na 30–120 sekund. 90% ruchu partnerów odbywa się z cache'a, produkcja nawet nie wie, że coś się dzieje.
• Waliduje wchodzące zapytania (rozmiar strony, dopuszczalne filtry), żeby nikt Ci nie wysłał GET /produkty?limit=99999999.
• Loguje każde zapytanie z timestampem, IP, ID klucza i czasem odpowiedzi. Jak coś pójdzie źle — masz dokładnie kiedy i kto.

Middleware to nie luksus, tylko warunek konieczny. Bez niego API nie jest interfejsem — jest dziurą w firmie.

5 zasad projektowania, których nie żałuje się po roku

Widzieliśmy dużo API zaprojektowanych „szybko na kolanie", które trzy lata później są kosztem, bo nie da się ich rozwinąć bez zepsucia partnerom. Kilka zasad, których warto się trzymać od pierwszego dnia:

1. Wersjonuj od początku. Ścieżka /api/v1/produkty, nie /api/produkty. Dodanie v2 za rok kosztuje wtedy dwie linijki kodu. Bez wersji — kosztuje renegocjację umów z partnerami.
2. Jeden endpoint = jeden zasób. /api/v1/produkty zwraca produkty, /api/v1/stany zwraca stany. Nie mieszaj wszystkiego w jednego „master-endpoint" tylko dlatego, że „tak wygodniej po stronie ERP".
3. Idempotencja tam, gdzie coś zapisujesz. Partner wysyła zamówienie z własnym numerem zewnętrznym. Jeśli wyśle dwa razy — dwa razy to samo, ale nie tworzą się dwa zamówienia. Bez tego pierwszą reklamacją będzie „wysłałem raz, macie dwa razy, kto to zapłaci".
4. Odpowiedzi zwięzłe, bez wewnętrznych ID. Zwracaj indeks produktu, kod EAN, nazwę, cenę — nie wewnętrzny ProductGuid, WarehouseZoneRefId i pola techniczne. Twoje wewnętrzne struktury się zmieniają — kontrakt z partnerem nie powinien.
5. Dokumentacja generowana z kodu. Swagger/OpenAPI dołączony do usługi. „Napiszemy dokumentację jak będzie czas" jest równoznaczne z „nie będzie dokumentacji nigdy", a bez niej partnerzy będą Cię pytać mailem o każdą literkę.

Bezpieczeństwo — czego naprawdę pilnować

Trzy elementy, które w praktyce dzielą API działające bez incydentów od tego, które wyciekło:

• HTTPS wymuszone, HTTP przekierowywane. Bez wyjątków, także w środowisku testowym. Klucz API wysłany przez HTTP jest kluczem publicznym.
• Rate limiting per klucz. Nawet jeśli ufasz partnerowi, tempo 5–100 zapytań/minuta chroni Cię przed nietrafionym kodem po ich stronie. Widzieliśmy skrypt partnera, który przez błąd rekurencji puszczał 3000 zapytań/minuta — bez limitu położyłby serwis.
• Rotacja kluczy raz na 6–12 miesięcy. Trywialne, prawie nigdy niewykonywane. Wpisz do umowy z partnerem i przypomnij mailem miesiąc wcześniej. Klucz, który nie jest rotowany przez 4 lata i był w mailu do byłego pracownika, to nie klucz — to zaproszenie.

Do tego zdrowe minimum: audit log wszystkich zapytań z 90-dniowym retention, alarm przy nietypowym ruchu (nagły wzrost 10x), oraz oddzielne konta w ERP dla operacji API — takie, które fizycznie nie mają uprawnień do modyfikowania kartotek, listy płac ani danych bankowych. API czyta i (w wąskim zakresie) tworzy zamówienia. Nic więcej.

Od czego zacząć

Jeśli w Twojej firmie ktoś zaczął mówić „chcemy mieć API do ERP", zrób w tej kolejności:

1. Spisz na jednej kartce, kto konkretnie i o co pyta. Nie „partnerzy", tylko trzej konkretni klienci i konkretne dane. Bez tego projektujesz API na przyszłość, która nigdy nie nadejdzie.
2. Policz godziny. Ile tygodniowo tracicie na te trzy prośby dziś? Pomnóż przez 50 tygodni. To Twój sufit budżetu na projekt.
3. Wybierz maksymalnie 4 endpointy na pierwszy release. Stany, cennik, zamówienie w jedną stronę, status. Reszta poczeka na v1.1.
4. Zdecyduj o warstwie pośredniej. Nawet najprostsze API musi mieć middleware — nie próbuj wystawiać Optimy „po SQL". Prosta usługa .NET z cache'em w Redisie wystarczy dla większości MŚP przez pierwsze dwa lata.
5. Zaplanuj 2–4 tygodnie na MVP, kolejny miesiąc na dokumentację, monitoring i onboarding pierwszego partnera. Nie planuj „na sześć miesięcy" — API projektowane sześć miesięcy nigdy nie wchodzi w życie.

Własne API nad ERP-em nie jest projektem ambicjonalnym „bo w korporacjach mają". Jest odpowiedzią na konkretną godzinę pracy handlowca, która dziś ginie w odpisywaniu na maile. Jeśli tych godzin jest 5 albo 10 tygodniowo — projekt zwraca się w pierwszym kwartale i przez kolejne lata pracuje sam z siebie.

Jeśli chcesz sprawdzić, czy w Twojej firmie to ten moment, ale nie masz czasu na miesiąc analizy, pomagamy MŚP rozłożyć to na czynniki pierwsze na 30-minutowej rozmowie. Bez slajdów.

API dla ERP nie jest projektem dla ambicji. Jest odpowiedzią na godzinę pracy tygodniowo, która dziś ginie w odpisywaniu na tego samego maila.

← Wróć na blog