Używamy plików cookie aby zapewnić działanie platformy oraz (opcjonalnie) analizować ruch. Wybierz swoje preferencje:
Co BaseLinker zautomatyzuje sam, a kiedy dołożyć Make albo n8n: CRM, raporty, zamówienia u dostawców i odpowiedzi z AI. Granica, API i koszty.
Akcje automatyczne w BaseLinkerze obsłużą zamówienie od pobrania do wysyłki: zmienią status, wystawią fakturę albo paragon, utworzą przesyłkę i wyślą klientowi wiadomość. Make albo n8n przydają się wtedy, gdy dane mają trafić poza BaseLinkera: do CRM, do raportu, do arkusza dostawcy albo do odpowiedzi pisanej z pomocą AI.
BaseLinker (marka Base) ma wbudowany moduł akcji automatycznych. Każda reguła składa się z trzech części: zdarzenia, warunków i akcji. Według pomocy Base dostępnych jest ponad 40 typów akcji, a do jednego zdarzenia można przypiąć wiele akcji z dowolną liczbą warunków (stan na październik 2026).
Zdarzenia dotyczą całego życia zamówienia. Najczęściej używane:
Akcje odpowiadają na to, co sprzedawca robi ręcznie w panelu: zmiana statusu, wysyłka e-maila i SMS-a do klienta, wystawienie faktury lub paragonu, utworzenie przesyłki i etykiety, zamówienie kuriera, wydruk dokumentów na wybranej drukarce, przekazanie zamówienia do hurtowni, rozdzielenie zamówienia.
Od wejścia KSeF dochodzą do tego reguły dla e-faktur. Base wysyła faktury do KSeF zaraz po wystawieniu albo po innym zdarzeniu, na przykład po spakowaniu zamówienia, i pozwala reagować na status faktury: wysłana, zaakceptowana, odrzucona, tryb offline. Szerzej o KSeF i o tym, czego Base w nim nie robi, piszemy we wpisie o KSeF i automatyzacji faktur.
Jeśli wszystkie Twoje kanały sprzedaży, kurierzy i program do faktur są na liście gotowych integracji Base, akcje automatyczne najczęściej wystarczą. Nie płacisz wtedy za dodatkowe narzędzie, a reguły zmieniasz sam w panelu.
Akcje działają na zamówieniach, produktach i dokumentach w BaseLinkerze. Granica pojawia się w czterech miejscach:
Prosty test: jeśli w opisie reguły pada nazwa systemu, którego nie ma w zakładce integracji Twojego konta Base, albo słowo „sprawdź” odnoszące się do danych spoza BaseLinkera, akcja automatyczna tego nie zrobi. Wtedy potrzebny jest scenariusz, który pobierze dane z obu stron.
Cztery typowe przepływy, w których BaseLinker zostaje źródłem danych, a scenariusz w Make albo n8n robi resztę:
Wspólny wzór: BaseLinker obsługuje zamówienie, a automatyzacja łączy je z systemami, o których BaseLinker nic nie wie. Jak taki przepływ wygląda dla zamówień z Allegro, opisujemy we wpisie o automatyzacji zamówień z Allegro do magazynu.
Przy podziale pracy trzymaj się jednej zasady: wszystko, co BaseLinker potrafi zrobić akcją automatyczną, zostaw w BaseLinkerze. Reguły w panelu zmieni każdy pracownik z dostępem, bez wzywania wykonawcy. Scenariusz w Make albo n8n odpowiada tylko za część, która wychodzi poza BaseLinkera. Najwięcej kłopotów sprawia sytuacja, w której ta sama rzecz dzieje się w dwóch miejscach, na przykład status zamówienia zmienia i akcja automatyczna, i scenariusz. Wtedy zamówienie potrafi przeskoczyć dwa statusy naraz albo dostać dwie faktury. Ustal z wykonawcą na piśmie, który system odpowiada za który krok, i zapisz to w dokumentacji projektu.
Przez API BaseLinkera. Według dokumentacji API (stan na październik 2026) wygląda to tak:
| Element | Jak działa |
|---|---|
| Adres | jeden adres connector.php, zapytania POST z nazwą metody i parametrami w JSON |
| Uwierzytelnianie | token API w nagłówku X-BLToken, token generujesz w panelu (Konto, Moje konto, API) |
| Limit | 100 zapytań na minutę |
| Zamówienia | metoda getOrders zwraca do 100 zamówień na wywołanie |
| Zdarzenia | dziennik zdarzeń (getJournalList) z ostatnich 3 dni: nowe zamówienie, płatność, zmiana statusu, faktura, paczka |
Dziennik zdarzeń trzeba włączyć w ustawieniach API, inaczej zwraca pustą odpowiedź. Scenariusz w Make albo n8n odpytuje go co kilka minut, zapamiętuje ostatnie przetworzone zdarzenie i reaguje tylko na nowe. To bezpieczniejsze niż pobieranie wszystkich zamówień od nowa, bo nie gubi zmian i oszczędza limit zapytań.
W Make i n8n zapytania do BaseLinkera buduje się zwykle modułem HTTP (w n8n węzłem HTTP Request), w którym podajesz adres, nagłówek z tokenem i treść zapytania. Token traktuj jak hasło: generuj go na swoim koncie, a po zakończeniu projektu wymień, jeśli wykonawca go widział. Szczegóły API, typowe połączenia i przepływ danych opisuje strona o integracji z BaseLinkerem.
Przy dużym ruchu limit 100 zapytań na minutę ma znaczenie. Scenariusz, który dla każdego zamówienia osobno pobiera produkty, stany i dane klienta, zużyje limit szybciej niż scenariusz pobierający zamówienia paczkami. To jedna z rzeczy, o które warto zapytać wykonawcę przed wyceną.
Widełki z katalogu procesów Qerify (szacunek zespołu, ostatni przegląd we wrześniu 2026):
| Proces | Koszt wdrożenia | Czas oszczędzany tygodniowo | Zwrot |
|---|---|---|---|
| Zamówienia ze sklepu i Allegro do systemu magazynowego | 3 000-9 000 zł | 8-12 h | 3-6 miesięcy |
| Synchronizacja cen i stanów między kanałami | 2 000-8 000 zł | 4-9 h | 3-6 miesięcy |
| Zamawianie towaru u dostawców | 3 000-9 000 zł | 5-10 h | 3-6 miesięcy |
| Raporty sprzedażowe z kilku źródeł | 2 500-8 000 zł | 4-10 h | 3-6 miesięcy |
| Odpowiedzi na powtarzalne zapytania klientów | 3 000-10 000 zł | 6-15 h | 2-5 miesięcy |
Do wdrożenia dolicz abonament Make albo koszt serwera dla n8n. Liczba operacji w Make rośnie z liczbą zamówień, więc przy kilkuset zamówieniach dziennie sposób odpytywania API wpływa też na rachunek za narzędzie. Opisy procesów, z przykładowym zakresem prac, znajdziesz na stronach zamówień do systemu magazynowego i synchronizacji cen i stanów.
Zanim zlecisz automatyzację, sprawdź, czy problemu nie rozwiąże jedna nowa akcja automatyczna w panelu Base. Jeśli nie rozwiąże, opisz Concierge'owi, czego nie robi Twój BaseLinker. Powstanie brief, a system dobierze wykonawców, którzy łączą BaseLinkera z innymi systemami. Więcej połączeń z polskimi systemami sprzedaży i księgowości znajdziesz na stronie integracji.