Integracja InPost z PrestaShop: Paczkomaty, kurier i automatyzacja wysyłki
Klient w koszyku wybiera dostawę do Paczkomatu, wskazuje konkretne urządzenie na mapie i finalizuje zamówienie. W panelu PrestaShop pojawia się nowe zamówienie, ale pole z wybranym punktem odbioru jest puste albo zawiera kod, którego nikt w magazynie nie rozpoznaje. Ktoś musi otworzyć wiadomość do klienta, odczytać numer punktu, ręcznie utworzyć przesyłkę w Managerze Paczek, pobrać etykietę, a na koniec wrócić do zamówienia i uzupełnić numer śledzenia. Nawet przy niewielkiej liczbie zamówień jest to uciążliwe. Przy większym wolumenie ręczna obsługa zaczyna zabierać znaczną część czasu zespołu. Ten scenariusz pokazuje, że integracja InPost z PrestaShop to coś więcej niż pokazanie logo Paczkomatu w checkoucie.
To połączenie kilku odrębnych elementów: wyboru metody dostawy, mapy punktów odbioru, zapisu tych danych w zamówieniu, utworzenia przesyłki po stronie InPost, wygenerowania etykiety i numeru śledzenia, a na końcu aktualizacji statusu zamówienia. Jeśli któryś z tych elementów działa niepoprawnie, reszta integracji może wyglądać na sprawną, a mimo to codziennie generować pracę ręczną, którą miała wyeliminować.
Z czego faktycznie składa się integracja InPost z PrestaShop
PrestaShop sam z siebie nie wie nic o Paczkomatach ani kurierach InPost. Rolę integracji pełni moduł albo zewnętrzny system, który spina ze sobą kilka warstw. Są to: wybór metody dostawy w checkoucie, mapę punktów odbioru, zapis wybranego punktu w danych zamówienia, komunikację z systemem InPost przy tworzeniu przesyłki, generowanie etykiety i numeru śledzenia, a na końcu aktualizację statusu zamówienia w panelu sklepu.
Z materiałów integracyjnych InPost wynika, że nie każda z tych warstw wymaga tego samego sposobu połączenia. Dostawa do Paczkomatu wymaga mechanizmu wyboru punktu odbioru, na przykład Geowidgetu albo innego rozwiązania korzystającego z aktualnych danych o lokalizacjach. Dostawa kurierska może działać w prostszym wariancie, w którym sklep jedynie oferuje tę metodę w checkoucie, a samo tworzenie przesyłki odbywa się poza PrestaShop, na przykład w Managerze Paczek lub WebTruckerze. Korzyść operacyjna pojawia się wtedy, gdy kolejne etapy, od wyboru dostawy po utworzenie przesyłki i przekazanie numeru śledzenia, tworzą spójny proces zamiast serii ręcznych kroków.
Moduł, Base czy własna integracja API: trzy różne podejścia
Sklep może połączyć się z InPost na kilka sposobów,. Każdy z nich ma inny sens biznesowy w zależności od skali sprzedaży i sposobu pracy zespołu.
Gotowy moduł PrestaShop instaluje się bezpośrednio z panelu administracyjnego sklepu. Obsługuje wybór Paczkomatu, kuriera i generowanie etykiet z poziomu zamówień PrestaShop. Sprawdza się w modelu, w którym PrestaShop jest jedynym albo głównym kanałem sprzedaży, a zespół pracuje bezpośrednio w panelu sklepu.
Zewnętrzny system klasy middleware, na przykład Base (dawniej BaseLinker), przejmuje obsługę zamówień z kilku kanałów jednocześnie, w tym z PrestaShop, i to on komunikuje się z InPost, a nie sam sklep. Rozwiązanie ma sens tam, gdzie PrestaShop jest jednym z kilku kanałów sprzedaży, na przykład obok Allegro, a magazyn potrzebuje jednego miejsca do obsługi wszystkich zamówień. O tym, jak wygląda taka architektura w praktyce, pisaliśmy przy okazji integracji PrestaShop z Allegro i Base.
Integracja własna, oparta bezpośrednio na API InPost, jest uzasadniona wtedy, gdy sklep ma nietypowy proces logistyczny, którego nie obsłuży ani gotowy moduł, ani middleware. Może to być na przykład własny system WMS z regułami przypisywania przesyłek, jakich żadne gotowe rozwiązanie nie przewiduje.
Żadne z tych podejść nie jest uniwersalnie lepsze. Wybór zależy od liczby kanałów sprzedaży, wolumenu zamówień, tego, czy sklep ma już wdrożony system ERP albo WMS, liczby obsługiwanych kurierów, istniejącej automatyzacji magazynu, tego, czy checkout jest niestandardowy, oraz konfiguracji multistore. Sklep ze stoma zamówieniami miesięcznie na jednym kanale sprzedaży ma inne potrzeby niż sklep obsługujący tysiące zamówień z pięciu kanałów jednocześnie, nawet jeśli oba korzystają z tego samego przewoźnika.
Kompatybilność z wersją PrestaShop: dlaczego to pierwsze pytanie, nie ostatnie
Zanim ktokolwiek zacznie konfigurować API, warto sprawdzić, czy wybrany moduł w ogóle obsługuje wersję silnika, na której działa sklep. Z oficjalnej strony integracyjnej InPost wynika, że dla polskiego rynku dostępne są osobne pakiety wtyczki: jeden dla PrestaShop 1.7 i osobny, łączony pakiet dla PrestaShop 8.x oraz 9.x. Moduł do obsługi InPost International jest dostępny wyłącznie dla PrestaShop 8.x/9.x, bez wersji dla 1.7.
Ma to znaczenie praktyczne. PrestaShop 9 wymaga co najmniej PHP 8.1. Dokumentacja PrestaShop dla wersji 9.0 wskazuje obsługę do PHP 8.4, natomiast gałąź 9.1x obsługuje PHP 8.1-8.5 i korzysta z Symfony 6.4. Dla PrestaShop 8.0-8.2 oficjalna dokumentacja wskazuje zgodność z PHP 7.2.5-8.1, przy czym rekomendowaną wersją jest PHP 8.1. Moduł przygotowany dla PrestaShop 1.7 może więc nie być zgodny ze środowiskiem nowszego sklepu, a pakiet dla 8.x/9.x nie powinien być traktowany jako zamiennik dla starszej gałęzi. PrestaShop 1.7 pozostaje starszą linią produktu, dlatego przy planowaniu większych zmian warto rozpatrywać moduł logistyczny razem z planem aktualizacji całego sklepu, a nie w oderwaniu od jego wersji.
Kompatybilność warto sprawdzać nie tylko przy pierwszym wdrożeniu, ale przy każdej większej zmianie: aktualizacji PrestaShop, zmianie wersji PHP na serwerze, wymianie motywu albo przebudowie checkoutu. Moduł, który działał poprawnie miesiąc temu, może przestać działać po jednej z tych zmian. Nawet jeśli nikt nie dotykał samej konfiguracji InPost. Jeśli sklep planuje migrację z PrestaShop 1.7 na nowszą wersję, warto potraktować wymianę modułu logistycznego jako element tego samego projektu, a nie osobne zadanie na później.
Klucz API, token dostępowy i ID organizacji
Warto od razu rozróżnić dwa rozwiązania, które mogą pojawiać się w dokumentacji InPost. ShipX to lokalne API wykorzystywane obecnie przez oficjalne materiały integracyjne PrestaShop dla polskiego rynku. Równolegle InPost rozwija Global API, czyli ujednolicony interfejs REST dla wielu rynków, z uwierzytelnianiem OAuth 2.1. Aktualny przewodnik migracji InPost wskazuje, że Polska należy do pierwszych rynków przechodzących stopniowo z lokalnych API do Global API. Dlatego nie należy zamiennie używać danych dostępowych z obu systemów: dopóki dokumentacja konkretnego modułu PrestaShop wymaga danych ShipX, trzeba konfigurować właśnie ShipX, a przejście na Global API wykonywać dopiero zgodnie z dokumentacją danego rozwiązania.
Dane dostępowe do ShipX generuje się samodzielnie w Managerze Paczek, bez konieczności zgłaszania się do działu wsparcia InPost. Proces wymaga dwóch elementów: Access Tokena, czyli tokenu dostępowego, oraz ID organizacji. Oba wprowadza się w konfiguracji modułu w panelu administracyjnym PrestaShop, razem z danymi nadawcy i adresem, z którego realizowane są wysyłki. Bez poprawnie uzupełnionych danych nadawcy moduł nie utworzy przesyłki, nawet jeśli sam token jest prawidłowy.
Osobnym elementem jest token do Geowidgetu, czyli mapy punktów odbioru w checkoucie. Aktualna wersja komponentu, Geowidget V5, wymaga własnego tokenu generowanego w Managerze Paczek w sekcji API. Jest to inny token niż Access Token ShipX używany do tworzenia przesyłek. Sklep może więc mieć poprawnie skonfigurowaną część magazynową integracji, a jednocześnie niedziałającą mapę w checkoucie, jeśli token Geowidgetu nie został dodany lub konfiguracja widgetu jest błędna.
Trzeba też rozróżnić poziom poufności tych danych. Access Token ShipX jest poświadczeniem dostępowym i powinien pozostawać po stronie serwera, w bezpiecznej konfiguracji modułu lub integracji. Token Geowidget V5 jest natomiast w oficjalnej dokumentacji określany jako token publiczny i jest przeznaczony do użycia w komponencie frontendowym. Nie należy więc traktować obu tokenów tak samo ani umieszczać sekretnego Access Tokena ShipX w kodzie szablonu, JavaScripcie czy publicznym repozytorium.
Geowidget i wybór Paczkomatu w koszyku
Wybór punktu odbioru w checkoucie to osobny element procesu, a nie tylko wizualny dodatek. Geowidget prezentuje dostępne urządzenia Paczkomat i PaczkoPunkty, pozwala klientowi wybrać lokalizację, a integracja sklepu musi następnie zapisać ten wybór przy zamówieniu i wykorzystać go przy tworzeniu przesyłki. Samo poprawne wyświetlenie mapy nie wystarcza, jeśli wybrany punkt nie trafia dalej do danych zamówienia.
Aktualny Geowidget V5 jest osadzany po stronie frontendu i korzysta z JavaScriptu. Oficjalne materiały InPost opisują go jako responsywny komponent pobierający aktualne informacje o punktach odbioru. Z perspektywy wdrożenia oznacza to, że trzeba sprawdzić nie tylko wygląd mapy, ale też jej działanie na urządzeniach mobilnych, reakcję na zmianę metody dostawy oraz prawidłowe przekazanie identyfikatora wybranego punktu do zamówienia.
Przy wdrożeniu i po większych zmianach w sklepie warto sprawdzić kilka scenariuszy diagnostycznych:
- mapa się nie ładuje – możliwą przyczyną jest m.in. błąd konfiguracji tokenu Geowidgetu, blokada skryptu albo konflikt JavaScript,
- wybrany punkt znika po przejściu do kolejnego kroku checkoutu – może to oznaczać, że niestandardowy checkout nie zachowuje poprawnie danych między krokami,
- checkout jednostronicowy albo mocno zmodyfikowany motyw nie renderuje widgetu prawidłowo z powodu sposobu obsługi skryptów lub hooków,
- cache, optymalizacja albo minifikacja skryptów mogą zakłócić ładowanie aktualnej wersji komponentu, dlatego test warto wykonać także przy docelowej konfiguracji wydajnościowej sklepu,
- klient wybiera punkt na mapie, ale punkt nie pojawia się w danych zamówienia – wtedy trzeba sprawdzić mechanizm zapisu i przekazywania danych, a nie tylko sam Geowidget.
Żaden z tych scenariuszy nie musi wystąpić w standardowym wdrożeniu. Ryzyko rośnie jednak przy niestandardowym checkoucie, zmodyfikowanym motywie lub dodatkowych mechanizmach optymalizacji frontendu. Dlatego test wyboru Paczkomatu powinien obejmować cały przepływ: od otwarcia mapy i wskazania punktu, przez złożenie zamówienia, po sprawdzenie danych w panelu i przy tworzeniu przesyłki. Zamówienie z dostawą do Paczkomatu bez wybranego punktu powinno być zatrzymane już na etapie checkoutu.
Paczkomat, kurier i pozostałe usługi InPost w konfiguracji sklepu
Zakres integracji może obejmować nie tylko dostawę do Paczkomatu i przesyłki kurierskie, ale również pobranie oraz wybrane usługi dodatkowe, takie jak Paczka w Weekend, ubezpieczenie, zwroty czy wysyłki międzynarodowe. Dostępność konkretnych funkcji zależy od wersji modułu, rodzaju integracji i usług aktywnych na koncie InPost. Przed uruchomieniem warto więc sprawdzić faktyczną konfigurację konta i modułu, zamiast zakładać, że każda funkcja opisana w materiałach InPost będzie automatycznie dostępna w danym sklepie.
Przy przesyłkach do urządzeń Paczkomat znaczenie ma również właściwy gabaryt A, B lub C. Nie należy jednak zakładać, że każdy moduł automatycznie wyliczy go z wymiarów wszystkich produktów w koszyku. Sposób przypisywania gabarytu zależy od konkretnej wtyczki i jej konfiguracji. Jeżeli reguły wysyłki korzystają z wagi lub wymiarów zapisanych w PrestaShop, dane produktowe muszą być kompletne i wiarygodne, inaczej automatyzacja może podjąć błędną decyzję.
Reguły wysyłki, które trzeba ustalić przed uruchomieniem
Zanim integracja InPost z PrestaShop trafi na produkcję, potrzebne jest kilka decyzji biznesowych, których żaden moduł nie podejmie automatycznie:
- które metody dostawy mają być widoczne dla których zamówień, na przykład czy kurier jest dostępny przy dużych lub ciężkich przesyłkach, których nie da się wysłać Paczkomatem,
- czy i od jakiej kwoty koszyka obowiązuje darmowa dostawa oraz czy próg jest inny dla Paczkomatu niż dla kuriera,
- czy płatność za pobraniem jest dostępna dla wszystkich metod dostawy, czy tylko wybranych,
- jak statusy zamówień PrestaShop mapują się na etapy realizacji przesyłki, na przykład czy zamówienie zmienia status automatycznie po wygenerowaniu etykiety,
- czy sklep obsługuje wysyłki międzynarodowe, a jeśli tak, to które kraje i za pomocą jakiej wersji modułu, ponieważ InPost International wymaga osobnej konfiguracji i osobnego pakietu integracyjnego.
Te reguły warto spisać przed konfiguracją modułu, a nie ustalać je na bieżąco w trakcie wdrożenia. Sama poprawna komunikacja z API nie oznacza jeszcze, że logika biznesowa działa prawidłowo. Osobno trzeba przetestować progi darmowej dostawy, dostępność metod dla różnych koszyków, pobranie, mapowanie statusów oraz scenariusze międzynarodowe, jeśli sklep z nich korzysta.
Automatyczne generowanie etykiet i przesyłek
Warto rozróżnić kilka procesów, które w rozmowie o automatyzacji często zlewają się w jedno: utworzenie zamówienia w sklepie, utworzenie przesyłki po stronie InPost, wygenerowanie numeru śledzenia i wygenerowanie samej etykiety do wydruku. To kroki powiązane, ale odrębne, i moduł nie musi wykonywać wszystkich naraz w każdym scenariuszu.
Dla pojedynczych zamówień integracja może umożliwiać utworzenie przesyłki i pobranie etykiety bezpośrednio z poziomu zamówienia, na podstawie danych odbiorcy, metody dostawy i parametrów przesyłki. Oficjalne materiały InPost dla PrestaShop opisują również masowe generowanie przesyłek, obsługę wielu paczek w jednym zamówieniu oraz szablony nadania. W zależności od modułu i używanego API etykiety mogą być dostępne m.in. w PDF oraz formatach przeznaczonych dla drukarek termicznych, takich jak ZPL czy EPL/EPL2. Przed wdrożeniem warto sprawdzić, które z tych funkcji obsługuje dokładnie wybrane rozwiązanie.
Automatyzacja nie musi oznaczać, że przesyłka powstaje natychmiast po złożeniu zamówienia. Część sklepów świadomie generuje przesyłkę dopiero po zaksięgowaniu płatności albo po potwierdzeniu kompletacji zamówienia w magazynie, żeby uniknąć sytuacji, w której etykieta istnieje dla zamówienia, które ostatecznie zostanie anulowane albo zmodyfikowane. To, na jakim etapie procesu ma się uruchamiać generowanie przesyłki, jest decyzją operacyjną, nie tylko techniczną. Warto ją podjąć świadomie, zamiast zostawiać na domyślnym ustawieniu modułu.
Statusy, śledzenie przesyłek, webhooki i CRON
Materiały InPost dotyczące integracji z PrestaShop opisują aktualizację statusów z wykorzystaniem webhooków oraz zadań CRON. Webhook działa zdarzeniowo. Po zmianie statusu InPost wysyła informację do wskazanego systemu, dzięki czemu aktualizacja może pojawić się bez czekania na kolejny cykl synchronizacji. Nie warto jednak nazywać tego gwarantowanym „czasem rzeczywistym”, bo dostarczenie i przetworzenie zdarzenia zależy od dostępności obu stron połączenia.
CRON może pełnić funkcję uzupełniającą, cyklicznie odpytując API i synchronizując dane. Jeżeli konkretny moduł wykorzystuje taki mechanizm, trzeba sprawdzić, czy zadania są rzeczywiście skonfigurowane i uruchamiane na serwerze. W przeciwnym razie sklep może utracić część automatycznej synchronizacji przewidzianej przez dane rozwiązanie, nawet jeśli sama konfiguracja w panelu wygląda poprawnie.
Dlatego warto zadbać o logowanie zdarzeń integracji, przynajmniej podstawowe zapisywanie informacji o nieudanych żądaniach do API, oraz o to, żeby ktoś w zespole faktycznie przeglądał te logi, zamiast dowiadywać się o problemie dopiero od klienta pytającego, gdzie jest jego paczka.
Checkout i doświadczenie klienta
Z perspektywy klienta cała ta warstwa techniczna sprowadza się do kilku prostych kroków: wyboru metody dostawy, wskazania konkretnego Paczkomatu na mapie albo pozostawienia dostawy kurierskiej, ewentualnej zmiany decyzji i finalizacji zamówienia bez utraty wcześniej wybranych danych. Każdy dodatkowy krok, zbędne przeładowanie strony czy problem z mapą na urządzeniu mobilnym zwiększa ryzyko przerwania procesu. Checkout jest szczególnie wrażliwym etapem ścieżki zakupowej. Sposób prezentacji i działania metod dostawy warto testować razem z całym procesem finalizacji. Więcej o projektowaniu tego etapu pisaliśmy przy okazji checkoutu PrestaShop.
Warto też pamiętać o walidacji: klient nie powinien mieć możliwości sfinalizowania zamówienia z dostawą do Paczkomatu bez wybrania konkretnego punktu, a przełączenie się z Paczkomatu na kuriera powinno czyścić wcześniej wybrany punkt, żeby w zamówieniu nie została sprzeczna kombinacja danych.
Jak wygląda bezpieczne wdrożenie integracji InPost krok po kroku
Bezpieczne wdrożenie powinno mieć jasno określoną kolejność i być przetestowane przed udostępnieniem klientom:
- Sprawdzenie zgodności wersji PrestaShop, PHP i wybranego modułu, zanim jakikolwiek plik trafi na serwer produkcyjny.
- Wygenerowanie danych dostępowych ShipX oraz tokenu Geowidgetu w Managerze Paczek.
- Konfiguracja modułu: dane nadawcy, metody dostawy, reguły wysyłki i progi darmowej dostawy.
- Testy na środowisku testowym sklepu oraz, jeśli wybrane API lub moduł to umożliwia, w odpowiednim środowisku testowym InPost, z wykorzystaniem scenariuszy z listy kontrolnej poniżej.
- Uruchomienie na produkcji z aktywnym logowaniem błędów i monitoringiem pierwszych zamówień.
Taka kolejność ogranicza ryzyko wykrycia problemu dopiero przy pierwszym realnym zamówieniu. Najpierw weryfikujemy zgodność środowiska i konfigurację, potem pełny przepływ danych, a dopiero na końcu uruchamiamy integrację na produkcji i obserwujemy pierwsze zamówienia.
Lista kontrolna przed uruchomieniem produkcyjnym
Zanim integracja InPost z PrestaShop trafi na produkcję, warto przejść przez konkretny zestaw scenariuszy testowych. Najlepiej zrobić to na kopii lub środowisku testowym sklepu, a jeżeli używane rozwiązanie udostępnia środowisko testowe API InPost, wykorzystać je również do weryfikacji komunikacji z przewoźnikiem:
- złożenie zamówienia z dostawą do Paczkomatu i sprawdzenie, czy wybrany punkt zapisał się poprawnie w danych zamówienia,
- złożenie zamówienia z dostawą kurierską,
- zamówienie z płatnością za pobraniem, jeśli sklep ją oferuje,
- pełna ścieżka zakupowa na urządzeniu mobilnym, nie tylko na desktopie,
- zamówienie złożone przez zalogowanego klienta oraz osobno jako gość,
- różne wartości koszyka, zwłaszcza w okolicach progu darmowej dostawy,
- produkty o różnej wadze i gabarycie, jeśli reguły wysyłki od tego zależą,
- wygenerowanie etykiety dla pojedynczego zamówienia i sprawdzenie poprawności danych na wydruku,
- masowe generowanie etykiet dla kilku zamówień naraz, jeśli sklep planuje z tego korzystać,
- sprawdzenie, czy numer śledzenia trafia do zamówienia i czy klient otrzymuje go w komunikacji e-mail,
- weryfikacja aktualizacji statusu zamówienia po zmianie statusu przesyłki,
- kontrolowany test obsługi błędu lub timeoutu API na środowisku testowym, jeśli zespół techniczny ma możliwość wykonania takiego scenariusza, wraz ze sprawdzeniem, czy błąd jest zapisany w logach,
- test przy włączonym cache strony, nie tylko na środowisku z wyłączonym cache,
- pełne przejście checkoutu po każdej aktualizacji modułu, nie tylko po pierwszym wdrożeniu,
- jeśli sklep korzysta z niestandardowego checkoutu, osobny test zgodności z tym konkretnym checkoutem, a nie tylko z domyślnym motywem.
Błędy i punkty awarii, które warto sprawdzić przy integracji InPost
Poniższa lista nie jest statystyką awarii. To zestaw miejsc, które warto świadomie zweryfikować, zamiast uznawać wdrożenie za poprawne po jednym testowym zamówieniu. Problemy ujawniające się dopiero po uruchomieniu integracji opisaliśmy szerzej w artykule o najczęstszych problemach z integracjami PrestaShop:
- moduł niezgodny z wersją PrestaShop albo PHP, na przykład pakiet przeznaczony dla 1.7 uruchamiany w środowisku sklepu 8.x/9.x,
- błędne albo niekompletne dane uwierzytelniające: sam token bez ID organizacji, albo dane z niewłaściwego środowiska, produkcyjnego zamiast testowego lub odwrotnie,
- pominięty token Geowidgetu przy poprawnie skonfigurowanym Access Tokenie do przesyłek, przez co mapa w checkoucie nie działa mimo pozornie gotowej integracji,
- niepełne albo błędne dane nadawcy, przez co moduł nie jest w stanie utworzyć przesyłki mimo poprawnego tokenu,
- metody dostawy zmapowane niezgodnie z rzeczywistą ofertą sklepu, na przykład kurier dostępny dla przesyłek, które faktycznie przekraczają obsługiwany gabaryt,
- wybrany punkt odbioru, który nie zapisuje się poprawnie w zamówieniu z powodu konfliktu w niestandardowym checkoucie,
- konflikt JavaScript między Geowidgetem a innym skryptem sklepu, który może ujawnić się po zmianie motywu, checkoutu albo konfiguracji frontendu,
- zadania CRON, które nie są uruchamiane na serwerze, przez co integracja traci mechanizm zapasowej synchronizacji statusów,
- brak logowania błędów API, przez co problem ujawnia się dopiero po zgłoszeniu klienta,
- testowanie wyłącznie jednej, najprostszej ścieżki zamówienia przed uruchomieniem produkcyjnym, bez sprawdzenia wariantów z listy kontrolnej powyżej,
- uruchomienie na produkcji bez pełnych testów na środowisku testowym sklepu i bez wykorzystania środowiska testowego API, jeśli jest dostępne dla wybranego sposobu integracji,
- aktualizacja modułu albo silnika PrestaShop bez ponownego przetestowania checkoutu i procesu generowania etykiet.
Co sprawdzić po aktualizacji PrestaShop
Integracja, która działała poprawnie przed aktualizacją silnika, aktualizacją PHP, wymianą motywu albo przebudową checkoutu, nie ma gwarancji, że będzie działać tak samo po takiej zmianie. Nie oznacza to, że każda aktualizacja psuje integrację z InPost, ale regresję warto sprawdzić celowo, a nie liczyć na to, że ewentualny problem sam się ujawni. Szczególną uwagę warto poświęcić checkoutowi i działaniu Geowidgetu, zapisowi danych zamówienia, generowaniu etykiet oraz temu, czy zapytania do API InPost w ogóle docierają poprawnie. Więcej o tym, jak aktualizacje PrestaShop wpływają na integracje i inne elementy sklepu, pisaliśmy w artykule o błędach po aktualizacji PrestaShop.
Kiedy do integracji potrzebny jest programista
Część konfiguracji da się przeprowadzić wyłącznie z poziomu panelu administracyjnego: wprowadzenie tokenu i ID organizacji, ustawienie danych nadawcy, włączenie poszczególnych usług czy skonfigurowanie progów darmowej dostawy. Programista staje się potrzebny w innych sytuacjach: gdy checkout jest niestandardowy i nie da się w nim po prostu osadzić domyślnego Geowidgetu, gdy moduł koliduje z motywem albo innymi skryptami frontendu, gdy struktura zamówienia w sklepie została wcześniej zmodyfikowana i nie odpowiada temu, czego oczekuje moduł, gdy do procesu musi włączyć się system ERP albo WMS, gdy sklep działa w konfiguracji multistore z różnymi regułami dla poszczególnych sklepów, gdy potrzebna jest dodatkowa automatyzacja wykraczająca poza to, co oferuje gotowy moduł, albo gdy błędy API wymagają realnego debugowania, a nie tylko sprawdzenia pola w panelu.
Źródło problemu może leżeć zarówno w samym module, jak i na styku modułu z resztą sklepu: motywem, checkoutem, innymi integracjami, konfiguracją serwera albo wcześniejszymi modyfikacjami. Dlatego przy trudniejszych błędach trzeba sprawdzać cały przepływ danych, a nie tylko ustawienia w panelu InPost.
Najczęściej zadawane pytania o integrację InPost z PrestaShop
Jak zintegrować InPost z PrestaShop?
Najprościej przez oficjalny moduł InPost, dostępny osobno dla PrestaShop 1.7 oraz dla PrestaShop 8.x/9.x. Instalacja odbywa się z panelu administracyjnego. Konfiguracja wymaga danych uwierzytelniających z Managera Paczek, Access Tokena i ID organizacji, oraz danych nadawcy. Przy większej liczbie kanałów sprzedaży alternatywą jest system klasy middleware, na przykład Base.
Czy istnieje moduł InPost do PrestaShop 8 i 9?
Tak. InPost udostępnia osobny pakiet integracyjny dla PrestaShop 8.x i 9.x, odrębny od pakietu przeznaczonego dla PrestaShop 1.7. Przed instalacją warto sprawdzić dokładną wersję PrestaShop i PHP na serwerze, bo moduł napisany pod jedną gałąź silnika nie musi działać poprawnie na drugiej.
Czy do integracji InPost z PrestaShop potrzebny jest programista?
Podstawową konfigurację, token, dane nadawcy, wybór usług, da się przeprowadzić samodzielnie z panelu administracyjnego. Programista jest potrzebny wtedy, gdy checkout jest niestandardowy, moduł koliduje z motywem lub innymi skryptami, sklep korzysta z multistore albo integracja ma się połączyć z systemem ERP czy WMS.
Skąd wziąć token API InPost?
Access Token ShipX i ID organizacji generuje się w Managerze Paczek. Osobno, w sekcji API tego samego panelu, tworzy się publiczny token Geowidgetu potrzebny do działania mapy punktów odbioru. To dwa różne rodzaje danych i pełnią inne funkcje. Access Token ShipX autoryzuje operacje logistyczne, a token Geowidgetu jest używany przez komponent mapy w interfejsie sklepu.
Dlaczego wybrany Paczkomat nie zapisuje się w zamówieniu?
Możliwe przyczyny to błąd przekazywania danych w niestandardowym checkoucie, konflikt JavaScript, problem z konfiguracją Geowidgetu albo mechanizm motywu, który nie zachowuje wybranego punktu między krokami. Warto sprawdzić to niezależnie od poprawności Access Tokena ShipX, bo wyświetlanie mapy i tworzenie przesyłek to odrębne elementy integracji.
Czy integrację trzeba testować po aktualizacji PrestaShop?
Tak. Aktualizacja silnika, zmiana wersji PHP, wymiana motywu albo przebudowa checkoutu mogą wpłynąć na działanie Geowidgetu, zapis danych zamówienia albo komunikację z API InPost. Może zdarzyć się tak, nawet jeśli sama konfiguracja modułu pozostała bez zmian.
Podsumowanie
Sama instalacja modułu nie wystarcza, żeby integracja InPost z PrestaShop działała niezawodnie. Trzeba jeszcze dopasować wersję modułu do silnika i PHP, poprawnie skonfigurować ShipX i Geowidget, ustalić reguły dostawy, sprawdzić zapis punktu odbioru, generowanie przesyłek i etykiet oraz przetestować statusy i obsługę błędów. Dopiero cały ten przepływ pokazuje, czy proces rzeczywiście ogranicza pracę ręczną zamiast przenosić ją z jednego miejsca do drugiego.
Jeśli standardowy moduł InPost nie pasuje do checkoutu sklepu, koliduje z motywem, wymaga połączenia z ERP albo WMS, albo przestał działać poprawnie po jednej z aktualizacji PrestaShop, wsparcie programistyczne Woohoo obejmuje weryfikację takiej integracji i wdrożenie brakujących zmian technicznych.
Zobacz też
- Integracja PrestaShop z Allegro: moduł, Base i bezpieczna synchronizacja sprzedaży
- Checkout PrestaShop: dlaczego klienci porzucają koszyk i jak poprawić proces zakupowy
- Integracja PrestaShop – najczęstsze problemy: jak je rozpoznać i skutecznie rozwiązać
Źródła
InPost, Integracja InPost z PrestaShop – od klucza API po masowe generowanie przesyłek, 25 maja 2026: https://inpost.pl/aktualnosci-integracja-inpost-z-prestashop-od-klucza-api-po-masowe-generowanie-przesylek
PrestaShop Developer Documentation, wymagania systemowe PrestaShop 8: https://devdocs.prestashop-project.org/8/basics/installation/system-requirements/
InPost, Integracja z InPost dla firm i sklepów internetowych (moduły PrestaShop, dokumentacja API): https://inpost.pl/integracja-z-inpost
PrestaShop Help Center, PHP version of PrestaShop 9: https://help-center.prestashop.com/hc/en-us/articles/27300983521554-PHP-version-of-PrestaShop-9
InPost, dokumentacja API ShipX: https://docs.inpost24.com/display/PL/API+ShipX
PrestaShop, cykl wydawniczy i zasady wsparcia wersji: https://www.prestashop-project.org/project-organization/release-cycle/
InPost Developers, uwierzytelnianie w Global API (OAuth 2.1): https://developers.inpost-group.com/authentication
InPost Developers, przewodnik migracji do Global API: https://developers.inpost-group.com/migration-guide
PrestaShop Build, PrestaShop 9.1 is available: https://build.prestashop-project.org/news/2026/prestashop-9-1-0-available/
InPost, dokumentacja Geowidget V5 (token publiczny i konfiguracja): https://geowidget.inpost.pl/docs/
