BaseLinker i n8n: jak buduję przepływ zamówień na API
BaseLinker zbiera zamówienia z wielu kanałów, a n8n robi z nimi to, czego nie obejmują wbudowane akcje automatyczne. Pokazuję, jak łączę oba narzędzia i na co uważam.
Autor: Szymon Łakomy. Aktualizacja:
Jak rozmawia się z API BaseLinkera
API BaseLinkera ma jeden adres. Każde zapytanie to POST z nazwą metody i parametrami w JSON. Token generuję w panelu, w ustawieniach API, i zapisuję w n8n jako poświadczenie typu Header Auth z nagłówkiem X-BLToken, a nie w treści węzła. Metody, których używam najczęściej:
- getJournalList: dziennik zdarzeń, czyli lista tego, co stało się z zamówieniami od ostatniego sprawdzenia.
- getOrders: szczegóły zamówienia, pozycje, dane do faktury i wysyłki.
- setOrderStatus i setOrderFields: zmiana statusu oraz pól dodatkowych.
- addInvoice: wystawienie faktury w module BaseLinkera, jeśli z niego korzystasz.
Nazwy i parametry metod sprawdzam w dokumentacji API przed każdym wdrożeniem, bo lista się rozrasta.
Dziennik zdarzeń zamiast pobierania wszystkich zamówień
Najczęstszy błąd w pierwszych przepływach to pobieranie co kilka minut wszystkich zamówień z ostatnich dni i porównywanie ich z arkuszem. To zjada limit zapytań i gubi zmiany. Dziennik zdarzeń działa lepiej, bo każdy wpis ma własny identyfikator, typ zdarzenia i numer zamówienia.
- Schedule Trigger uruchamia przepływ co kilka minut.
- Przepływ wczytuje identyfikator ostatniego obsłużonego wpisu, zapisany w tabeli danych n8n.
- getJournalList zwraca nowsze wpisy, a węzeł Switch kieruje je według typu: nowe zamówienie, płatność, zmiana statusu, wystawiona faktura, utworzona paczka.
- Każda gałąź pobiera tylko te zamówienia, których dotyczy zdarzenie.
- Na końcu przepływ zapisuje identyfikator ostatniego wpisu, więc kolejny przebieg zaczyna od tego miejsca.
Przykładowy przepływ: od opłaconego zamówienia do wiadomości
Załóżmy, że sklep sprzedaje przez własną stronę i Allegro, a zamówienia zbiera w BaseLinkerze. Zdarzenie płatności uruchamia gałąź, która:
- sprawdza, czy klient podał NIP, i wybiera rodzaj dokumentu,
- wystawia fakturę w programie do faktur albo w module BaseLinkera,
- ustawia status „Do spakowania” i dopisuje numer dokumentu w polu dodatkowym,
- przy produktach na zamówienie wysyła klientowi wiadomość z przewidywanym terminem,
- zamówienia z nietypowym adresem albo wyjątkowo wysoką kwotą przekazuje do sprawdzenia na kanał zespołu.
W ramach Today Automate automatyzacja obsługi zamówień w Superksiążce według klienta zastąpiła półtora etatu i zwróciła się w miesiąc, a w Pakujemy.pl odciążyła zespół z powtarzalnych zadań. Oba opisy są w realizacjach.
Limity, ponowienia i podwójne akcje
Limit zapytań
BaseLinker ogranicza liczbę zapytań na token w czasie. W węźle HTTP Request ustawiam partie z odstępem, a szczegóły wielu zamówień pobieram jednym zapytaniem zamiast osobno.
Ponowienie po błędzie
Włączam Retry On Fail z przerwą między próbami. Błąd, który powtarza się kilka razy, trafia do Error Workflow i do wskazanej osoby.
Jedna faktura na zamówienie
Zanim przepływ wystawi dokument, sprawdza, czy zamówienie już go ma. Ponowny przebieg tego samego wpisu z dziennika nie stworzy drugiej faktury.
Statusy jako umowa
Spisuję, które statusy ustawia człowiek, a które przepływ. Gdy obie strony zmieniają ten sam status, zamówienia zaczynają skakać między etapami.
Przepływ w n8n czy szersza integracja
n8n sprawdza się, gdy BaseLinker ma reagować na zdarzenia i wymieniać dane z kilkoma usługami: programem do faktur, arkuszem, komunikatorem, pocztą. Gdy w grę wchodzi synchronizacja stanów z ERP, kilka magazynów albo własny panel, projektuję szersze połączenie opisane na stronie integracja BaseLinker. Jeśli zastanawiasz się, czy w ogóle zostać przy tym systemie, przeczytaj tekst alternatywa dla BaseLinkera.
Inne przepływy na polskich systemach zbieram w gotowych scenariuszach n8n. To, co jeszcze warto oddać automatom w sklepie, opisuję w poradniku co zautomatyzować w sklepie internetowym.
Najczęstsze pytania
Czy do BaseLinkera w n8n warto użyć węzła społeczności?
Można, ale w przepływach firmowych wolę zwykły węzeł HTTP Request. Węzeł społeczności zależy od tempa pracy jego autora, a przy zmianie w API trzeba czekać na aktualizację. Zapytanie HTTP poprawiam od razu.
Czy przepływ zadziała od razu po złożeniu zamówienia?
Przy odpytywaniu dziennika opóźnienie wynosi tyle, ile odstęp między przebiegami. Dla faktur i statusów to zwykle wystarcza. Gdy coś musi dziać się natychmiast, sprawdzam, czy akcje automatyczne w Twoim koncie mogą wywołać webhook n8n.
Czy zmiana w n8n może popsuć zamówienia w BaseLinkerze?
Może, jeśli testuje się na żywym koncie. Nowe gałęzie uruchamiam więc najpierw w trybie, który tylko zapisuje planowane zmiany w arkuszu. Zapis do BaseLinkera włączam dopiero po porównaniu z rzeczywistością.
Ile kosztuje przepływ BaseLinker w n8n?
Prosty przepływ, na przykład zmiana statusu i wiadomość do klienta po wystawieniu faktury, zaczyna się od około 500 zł netto. Kilka gałęzi z wyjątkami i obsługą błędów to złożony przepływ, od około 2000 zł netto. Do tego serwer n8n, jeśli go jeszcze nie masz.
Powiązane strony
Chcesz spiąć BaseLinker z n8n?
Opisz, co dziś robisz ręcznie po wpłynięciu zamówienia. Wskażę, które kroki przejmie przepływ.