Shoper i PrestaShop: automatyzacja bez wtyczek 2026 (czyli jak obejść ubogie API przez n8n)

Większość tekstów o automatyzacji sklepu internetowego, jakie można znaleźć w polskim internecie, w rzeczywistości opisuje jeden konkretny zestaw: WooCommerce plus Allegro i Baselinker. Nie jest to przypadek. WooCommerce ma otwarte, dobrze udokumentowane REST API z natywnymi webhookami na każde praktycznie zdarzenie, a ekosystem wtyczek jest tak duży, że ktoś już napisał to, czego potrzebujesz. Allegro ma własne, rozwijane API, a Baselinker żyje z tego, że scala różne kanały sprzedaży w jedno miejsce. Pisanie poradnika o automatyzacji w takim środowisku jest wygodne, bo wszystko jest gotowe.

Problem zaczyna się wtedy, kiedy klient prowadzi sklep na Shoperze albo PrestaShop i chce to samo: automatyczne etykiety kurierskie, synchronizację stanów magazynowych i wystawianie faktur w KSeF bez przepisywania danych. W naszych wdrożeniach to jest dziś jeden z częstszych scenariuszy, bo Shoper jest jedną z najpopularniejszych platform SaaS dla mniejszych i średnich sklepów w Polsce, a PrestaShop od lat trzyma się jako wybór sklepów, które chcą mieć kod u siebie i nie płacić miesięcznego abonamentu za samo istnienie witryny. Oba mają realne ograniczenia techniczne, o których mało kto pisze, bo mało kto je wdrażał w praktyce.

Dlaczego Shoper i PrestaShop to inna liga niż WooCommerce

W WooCommerce webhook to kilka kliknięć w panelu: wybieram zdarzenie, wklejam adres, gotowe. System sam wysyła powiadomienie do n8n albo Zapiera przy każdej zmianie statusu zamówienia, aktualizacji stanu magazynowego czy nowym kliencie. Na Shoperze i PrestaShop to już nie jest tak proste, i to jest pierwsza rzecz, którą trzeba sobie powiedzieć wprost, zamiast odkrywać to po dwóch tygodniach prac wdrożeniowych.

Shoper: webhooki są, ale węższe niż się wydaje

Shoper udostępnia REST API i mechanizm webhooków, co samo w sobie jest plusem w porównaniu z wieloma innymi polskimi platformami SaaS. Problem w praktyce jest inny: zestaw zdarzeń, na które można się zapisać, jest dużo skromniejszy niż w WooCommerce, dostęp do pełnego API bywa związany z wyższym planem abonamentowym (w niższych pakietach część funkcji API i integracji jest po prostu niedostępna albo wymaga dopłaty), a dokumentacja techniczna nie jest tak rozbudowana jak w przypadku dużych platform open-source. W efekcie część zdarzeń, które chcielibyśmy obsłużyć w czasie rzeczywistym, trzeba domykać odpytywaniem API w regularnych odstępach, bo webhook po prostu nie istnieje dla danego typu zmiany.

PrestaShop: webservice bez webhooków na zewnątrz

PrestaShop ma dojrzałe API (tzw. Webservice, REST/XML), ale to narzędzie stworzone głównie do tego, żeby zewnętrzny system mógł odczytać albo zapisać dane na żądanie, nie do tego, żeby sklep sam z siebie informował świat o zmianach. System hooków w PrestaShop działa po stronie PHP, wewnątrz instalacji, i jest przeznaczony dla modułów, nie dla zewnętrznych adresów URL. Żeby sklep na PrestaShop realnie powiadamiał n8n o nowym zamówieniu, trzeba albo napisać prosty moduł, który przy odpowiednim hooku (np. actionOrderStatusPostUpdate) wyśle zapytanie HTTP na zewnątrz, albo zrezygnować z powiadomień i budować cały proces na regularnym odpytywaniu API co kilka minut. Obie opcje są wykonalne, ale żadna nie jest „kliknij i działa”.

KSeF w sklepie na Shoperze i PrestaShop: terminy już nie są odległe

Krajowy System e-Faktur staje się obowiązkowy etapami: od 1 lutego 2026 dla firm, których sprzedaż w 2025 roku przekroczyła 200 mln zł, a od 1 kwietnia 2026 dla pozostałych czynnych podatników VAT. Dla sklepu internetowego to oznacza, że każda faktura B2B wystawiona klientowi będącemu podatnikiem VAT musi trafić do KSeF jako ustrukturyzowany dokument XML, a nie jako PDF wysłany mailem.

W WooCommerce temat KSeF obrósł już kilkoma wtyczkami i gotowymi integracjami z systemami księgowymi. Na Shoperze i PrestaShop taki ekosystem po prostu nie istnieje w podobnej skali. Część biur rachunkowych i dostawców oprogramowania księgowego (typu Comarch Optima, wFirma, Fakturownia, iFirma) ma własne moduły KSeF, ale to narzędzia działające po stronie systemu księgowego, nie sklepu. Zadanie, które zostaje do rozwiązania, jest zawsze to samo: dane z zamówienia na Shoperze czy PrestaShop trzeba przenieść do systemu, który faktycznie wysyła faktury do KSeF, i zrobić to bez ręcznego przepisywania pozycji zamówienia.

Jeśli sklep wystawia dziennie kilkadziesiąt faktur B2B, a ktoś w księgowości przepisuje dane zamówienia do systemu fakturowego ręcznie, to jest to pierwsze miejsce, gdzie szukałbym automatyzacji, zanim zajmę się czymkolwiek innym. Dobrze zaprojektowany przepływ w n8n potrafi odebrać dane zamówienia z Shopera przez API, zmapować je na strukturę faktury i wysłać do systemu księgowego albo bezpośrednio do KSeF przez jego API, bez udziału człowieka w typowym przypadku. Szczegóły tego, jak to wygląda technicznie w szerszym ujęciu, opisujemy przy okazji automatyzacji faktur, bo mechanika mapowania pozycji i statusów jest tam podobna niezależnie od platformy sklepowej.

Jak w praktyce spiąć kuriera, magazyn i KSeF przez n8n

n8n sprawdza się tutaj lepiej niż gotowe integracje z kilku powodów. Pierwszy to elastyczność: skoro nie ma webhooka na dane zdarzenie, n8n pozwala postawić harmonogram, który odpytuje API Shopera albo PrestaShop co 2-5 minut i sam wykrywa zmiany, porównując stan z ostatnim zapisem. Drugi powód to kontrola nad logiką pośrednią, czyli wszystkim tym, co dzieje się między „zamówienie złożone” a „faktura wysłana do KSeF”, a to właśnie tam najczęściej leżą reguły specyficzne dla danej firmy (inny magazyn dla towarów importowanych, inna stawka VAT dla eksportu, inny kurier dla przesyłek gabarytowych).

Etykiety kurierskie: InPost, DPD, DHL

Shoper ma wbudowane integracje z głównymi kurierami w panelu, co jest jego przewagą nad PrestaShop i warto to wykorzystać tam, gdzie wystarczają standardowe reguły (np. jeden kurier dla całego asortymentu). Tam, gdzie potrzeba czegoś więcej, na przykład automatycznego wyboru kuriera w zależności od wagi, wartości zamówienia albo kraju dostawy, warto podłączyć się bezpośrednio do API przewoźnika (InPost ma dobrze udokumentowane REST API, podobnie DPD i DHL) z n8n, zamiast wymuszać to przez panel sklepu. Na PrestaShop sytuacja jest odwrotna: oficjalny moduł InPost jest solidny, ale integracje z DPD i DHL często pochodzą od zewnętrznych dostawców modułów, bywają płatne i nie zawsze nadążają z aktualizacjami po większych zmianach w PrestaShop. W wielu naszych wdrożeniach było po prostu szybciej i stabilniej zbudować generowanie etykiet w n8n, niż polegać na module z marketplace, który traci wsparcie po dwóch latach.

Magazyn i stany, zanim ktoś sprzeda produkt, którego nie ma

Synchronizacja stanów magazynowych między sklepem i systemem WMS albo arkuszem Excel (tak, nadal często to arkusz) to klasyczny przypadek, gdzie brak webhooka na PrestaShop boli najbardziej. Jeśli stan produktu zmienia się w kilku miejscach (sklep stacjonarny, magazyn, drugi kanał sprzedaży), a synchronizacja działa tylko raz dziennie przez nocny import CSV, prędzej czy później ktoś sprzeda towar, którego fizycznie nie ma na stanie. Rozwiązaniem, które się u nas sprawdza, jest pollowanie API co kilka minut dla produktów z niskim stanem (poniżej ustalonego progu) i reagowanie w czasie bliższym rzeczywistemu tylko tam, gdzie to ma sens biznesowy, a nie próba robienia tego dla całego katalogu, bo to niepotrzebnie obciąża API i naraża na limity zapytań.

KSeF: od zamówienia do faktury bez przepisywania

Tu scenariusz wygląda tak: n8n wykrywa nowe zamówienie lub zmianę jego statusu na „zrealizowane”, pobiera dane klienta i pozycje zamówienia przez API Shopera lub PrestaShop, mapuje je na strukturę wymaganą przez system fakturowy obsługujący KSeF i wysyła żądanie wystawienia faktury. Jeśli firma już korzysta z systemu księgowego mającego własne API do KSeF, n8n działa jako łącznik między dwoma systemami, które inaczej nigdy by się ze sobą nie dogadały. Jeśli nie, trzeba też rozważyć pośrednie API samego KSeF, co jest rozwiązaniem bardziej pracochłonnym na starcie, ale dającym pełną kontrolę nad formatem i terminowością wysyłki.

Gdzie ta automatyzacja ma sens, a gdzie nie

Automatyzacja oparta na pollowaniu API, bo tak w uczciwym ujęciu trzeba nazwać większość tych rozwiązań na Shoperze i PrestaShop, nie jest idealna i nie udaję, że jest. Odpytywanie API co kilka minut zamiast reagowania na webhook w ułamku sekundy oznacza opóźnienie, zwykle rzędu kilku minut, w aktualizacji stanu zamówienia czy magazynu. Dla sklepu wysyłającego kilkadziesiąt zamówień dziennie to opóźnienie nie ma żadnego znaczenia biznesowego. Dla sklepu z dużym natężeniem zamówień flash sale czy dropshippingu z bardzo wąskimi marginesami na stan magazynowy, gdzie liczy się każda minuta, trzeba to wziąć pod uwagę przy projektowaniu procesu i czasem zaakceptować, że część decyzji (np. ręczna blokada sprzedaży przy bardzo niskim stanie) musi zostać po stronie człowieka, a nie automatu.

Drugie realne ograniczenie to limity zapytań do API. Zarówno Shoper, jak i PrestaShop mają górne granice liczby żądań w jednostce czasu, a przy częstym pollowaniu dla wielu produktów naraz łatwo w nie trafić. Dlatego w praktyce automat robi dobrze 80-90% pracy (odczyt zamówień, generowanie etykiet, wysyłka faktur w standardowych przypadkach), a decyzję przy wyjątku, na przykład niezgodności NIP-u, braku towaru po przyjęciu zamówienia albo nietypowej reklamacji, zostawiamy człowiekowi. Próba zautomatyzowania wszystkiego do końca zwykle kończy się systemem, który nikt nie rozumie i nikt nie chce utrzymywać po pół roku.

Nie polecałbym też zaczynania automatyzacji od razu od KSeF, jeśli sklep nie ma jeszcze poukładanej synchronizacji zamówień i magazynu. Lepiej najpierw ustabilizować przepływ danych między sklepem, kurierem i magazynem, a KSeF dołożyć jako kolejny krok korzystający z już sprawdzonego pobierania danych zamówienia. Odwrotna kolejność, czyli budowanie integracji fakturowej na niestabilnych danych źródłowych, kończy się powtarzaniem tej samej pracy dwa razy.

Ile to realnie kosztuje i od czego zacząć

Dostęp do pełnego API bywa ograniczony niższymi planami abonamentowymi Shopera, więc pierwszym krokiem zawsze jest sprawdzenie, czy obecny pakiet w ogóle daje dostęp do potrzebnych endpointów i webhooków, zanim ktokolwiek zacznie projektować przepływ w n8n. Na PrestaShop koszt leży gdzie indziej: nie w abonamencie (bo to oprogramowanie open-source), a w hostingu z odpowiednią wydajnością na regularne odpytywanie API i w czasie programisty potrzebnym na napisanie prostego modułu wysyłającego powiadomienia na zewnątrz, jeśli webhooki mają być bliższe rzeczywistości.

Sama platforma n8n może działać w wersji self-hosted, co ogranicza koszty do serwera, albo w wersji chmurowej, gdzie płaci się za liczbę wykonań. Dla sklepu średniej wielkości to zwykle koszt rzędu dziesiątek, nie tysięcy złotych miesięcznie, znacznie mniej niż utrzymanie osoby przepisującej dane między systemami. Jeśli sklep działa w szerszym ekosystemie, warto od razu spojrzeć na to szerzej, bo wiele tych samych mechanizmów (synchronizacja stanów, powiadomienia, obsługa zamówień) powtarza się w różnych projektach e-commerce, co pokazujemy przy automatyzacji sklepów internetowych jako całości, a nie pojedynczych integracji punktowych.