Komunikat „możesz śledzić do 5 paczek jednocześnie” pojawia się w aplikacji mobilnej kuriera albo w panelu śledzenia na stronie przewoźnika. To limit interfejsu, a nie fizyczna liczba paczek, które możesz wysłać lub odebrać. Sklep korzystający z API kuriera nie ma takiego ograniczenia w sposobie wyświetlania przesyłek, bo nie pracuje na widoku dla konsumenta. Limit dotyczy jednoczesnego śledzenia, a nie liczby zamówień w historii. Poniżej wyjaśniamy, gdzie realnie spotkasz limit 5 paczek i jak śledzić więcej przesyłek.
Komunikat „możesz śledzić do 5 paczek jednocześnie” pojawia się najczęściej w dwóch miejscach: w aplikacji mobilnej kuriera oraz w panelu śledzenia na stronie przewoźnika. Za każdym razem oznacza dokładnie to samo – skończyło się miejsce na liście obserwowanych przesyłek w widoku dla konsumenta.
To limit interfejsu, nie logistyki. Kurier przyjmie od Ciebie szóstą, dwudziestą i dwusetną paczkę. Jeśli wyślesz 300 przesyłek w miesiącu, wszystkie zostaną doręczone – po prostu nie wszystkie naraz zmieszczą się na ekranie „śledź przesyłkę”. Limit dotyczy jednoczesnego śledzenia, nie liczby zamówień w historii. Archiwum przesyłek i historia zamówień to osobne ekrany z osobnymi (zwykle znacznie większymi) ograniczeniami.
Drugie rozróżnienie: konsument kontra sklep. Sprzedawca, który pobiera statusy przez API kuriera, nie ma tego limitu w sposobie wyświetlania przesyłek. Panel sklepu czyta dane z własnej bazy i pokazuje je w tabeli z filtrami oraz paginacją – na jednym ekranie może być 20, 50 albo 500 zamówień. API zwraca dane partiami, po kilkadziesiąt rekordów na zapytanie, a nie „5 aktywnych pozycji”.
Pułapka numer jeden: mieszanie trzech różnych ograniczeń. Limit w aplikacji to wygoda producenta aplikacji. Limit w umowie z kurierem dotyczy wolumenów i ceny. Limit API (rate limit, liczba zapytań na minutę) to jedyne ograniczenie, które realnie boli przy integracji sklepu. Jeśli planujesz wysyłkę 500 paczek dziennie, ustal z kurierem limit zapytań, zanim wdrożysz synchronizację statusów.
Warto też wiedzieć, że limit jest ruchomy: gdy przesyłka zmieni status na „doręczona” i zniknie z listy aktywnych, zwalnia się miejsce. Jak wygląda odbiór bez ręcznego sprawdzania statusów, opisujemy w tekście odbiór paczek bez ręcznego sprawdzania statusów.
Aplikacje konsumenckie różnią się między sobą nie tylko liczbą miejsc na liście, ale też sposobem dodawania numeru. W InPost Mobile najczęściej wpisujesz numer z SMS-a powiadomienia albo skanujesz etykietę. W aplikacjach DPD i DHL podajesz numer listu przewozowego lub klikasz link z maila od nadawcy. Nie zakładaj konkretnej liczby na sztywno – producenci zmieniają ją przy aktualizacjach i część przesyłek „historycznych” chowa się w archiwum, a nie na liście aktywnych.
Trackery zbiorcze, takie jak AfterShip albo 17track, działają na innym modelu rozliczania. Na planie darmowym liczy się zwykle miesięczny wolumen dodanych przesyłek, a nie liczba otwartych kart w przeglądarce. Po przekroczeniu progu import CSV albo zapytanie do API przestaje przyjmować nowe numery – trzeba przejść na plan płatny. Dlatego przy 200 paczkach miesięcznie tracker zbiorczy ma sens, a przy 5 000 paczek taniej wychodzi własna integracja z API kuriera.
Formularz „śledź przesyłkę” na stronie przewoźnika to najprostszy przypadek: jedno pole, jeden numer, jeden wynik. Nie ma tu żadnej listy, więc limit nie występuje – ale przy 30 paczkach dziennie oznacza 30 ręcznych wpisań.
Osobna kategoria to konta B2B u kurierów. Zamiast listy „obserwowanych” dostajesz wyszukiwarkę, eksport zamówień do CSV i dostęp do API. Limity są inne niż w aplikacji konsumenckiej i zwykle określone w umowie. Uwaga na pułapkę: ten sam adres e-mail założony raz jako konto prywatne, raz jako firmowe – to dwa różne widoki, dwa różne limity i dwa różne sposoby dodawania numerów.
| Miejsce | Typ dostępu | Jak dodajesz numer | Realne ograniczenie |
|---|---|---|---|
| InPost Mobile | konto konsumenta | numer z SMS, skan etykiety | lista aktywnych przesyłek; dokładna liczba zależy od wersji aplikacji |
| Aplikacja DPD | konto konsumenta | numer listu przewozowego, link z maila | kilka pozycji na liście obserwowanych |
| Aplikacja DHL | konto konsumenta | numer przesyłki, kod śledzenia | ograniczona lista zapisanych przesyłek |
| Formularz „śledź przesyłkę” na stronie kuriera | bez konta | jeden numer | jedna przesyłka na raz |
| Tracker zbiorczy (AfterShip, 17track) | konto darmowe lub płatne | ręcznie, import CSV, API | limit miesięcznego wolumenu zależny od planu |
| Panel B2B / API kuriera | konto firmowe | integracja, eksport CSV, webhook | brak limitu interfejsu; obowiązuje limit zapytań API na minutę |
1. Konto firmowe i API zamiast aplikacji konsumenckiej. Rejestrujesz konto biznesowe u kuriera, generujesz token API i pobierasz statusy partiami, np. po 50 numerów na jedno zapytanie. 400 paczek dziennie to wtedy 8 zapytań, a nie 400 wejść do aplikacji. W PrestaShop integrację robi się najczęściej jako moduł korzystający z warstwy usług – punkt startowy znajdziesz w dokumentacji dla deweloperów PrestaShop. Sprawdź w niej, jak wygląda rejestracja modułu i obsługa konfiguracji.
2. Webhooki zamiast odpytywania co minutę. Zamiast pytać kuriera „czy coś się zmieniło?” 1 440 razy na dobę, wystawiasz endpoint HTTPS i to kurier wysyła powiadomienie, gdy status się zmieni. Efekt: nie wpadasz w rate limit, a status trafia do sklepu w sekundach, nie w minutach. Dwie pułapki: webhooki potrafią się powtórzyć, więc zapisuj statusy idempotentnie po numerze przesyłki, i zawsze weryfikuj podpis lub nagłówek autoryzacyjny.
3. Tracker zbiorczy z importem CSV. Przygotowujesz plik z jedną kolumną numerów, kodowanie UTF-8, separator przecinek. Narzędzia przyjmują zwykle od kilkudziesięciu do kilkuset wierszy na import, zależnie od planu. Pilnuj duplikatów – ten sam numer dodany dwa razy zjada limit z planu i dubluje powiadomienia.
4. Powiadomienia e-mail i SMS z linkiem do statusu. Zamiast zaglądać do panelu, ustaw w sklepie automatyczne wiadomości na zmianę statusu: „wysłane”, „w drodze”, „do odbioru”, „doręczone”. Klient klika link i widzi status strony kuriera, a Ty w panelu robisz jeden widok „przesyłki wymagające uwagi”. To najtańsza optymalizacja, jeśli nie chcesz budować integracji.
Limit pięciu śledzonych przesyłek nie wynika z przepisów ani z umowy z kurierem. To decyzja projektowa po stronie przewoźnika. Ma trzy praktyczne źródła.
Ochrona API przed scrapingiem. Publiczny endpoint śledzenia jest jednym z najczęściej odpytywanych miejsc w całym API kuriera. Wystarczy jeden skrypt, żeby w ciągu godziny sprawdzić dziesiątki tysięcy numerów przesyłek – nie po to, żeby cokolwiek odebrać, ale żeby zebrać dane. Dlatego przewoźnicy wiążą liczbę śledzonych paczek z sesją w aplikacji lub z kontem użytkownika i dokładają rate limiting. Typowe mechanizmy, które zobaczysz w dokumentacji, to kod HTTP 429 „Too Many Requests”, nagłówek Retry-After oraz limity liczone osobno na token, na adres IP i na konto.
Koszty infrastruktury. Każde zapytanie o status to odczyt z bazy zdarzeń, często po stronie kilku systemów jednocześnie: sortowni, oddziału, punktu odbioru. Przy dziesiątkach milionów zapytań dziennie różnica między „5 na użytkownika” a „bez limitu” to realne koszty serwerów i utrzymania zespołu, który pilnuje dostępności.
Prostota dla odbiorcy. Przeciętny klient śledzi jedną, maksymalnie dwie paczki – własną i ewentualny zwrot. Ekran z pięcioma polami jest czytelny i nie wymaga tłumaczenia. Lista z pięćdziesięcioma numerami wpisywanymi ręcznie nie jest.
Konkretnych wartości „ile zapytań na minutę” tu nie podamy. Każdy kurier ustala je osobno, inaczej dla środowiska testowego i produkcyjnego, i zmienia je razem z kolejnymi wersjami API. Te liczby są w dokumentacji dla deweloperów danego przewoźnika. Zamiast ich zgadywać, zapytaj wykonawcę o dwie rzeczy: jaki limit obowiązuje na token i co dokładnie dzieje się w sklepie, gdy ten limit zostanie przekroczony.
W PrestaShop numer śledzenia masz wbudowany. W karcie zamówienia, w zakładce dostawy, znajduje się pole „Numer śledzenia”. W konfiguracji przewoźnika (Zamówienia → Kurierzy → edycja) wpisujesz wzór adresu URL śledzenia z placeholderem @ – PrestaShop podstawi w to miejsce numer przesyłki i wygeneruje klikalny link przy zamówieniu. Statusy zamówień mają przypisane szablony maili (pliki .html i .txt w katalogu mails/), więc po zmianie statusu na „Wysłane” klient dostaje wiadomość z linkiem. Czego domyślnie nie ma? Automatycznego pobierania statusów z API kuriera. To już praca dla modułu albo własnego kodu.
W WooCommerce nie ma natywnego pola na numer śledzenia. Jest zamówienie, zestaw statusów (w tym wc-completed) i mail „Zrealizowane zamówienie”, do którego możesz dopisać własną treść. Numer przesyłki dodajesz wtyczką (np. Shipment Tracking) albo własnym polem meta (_tracking_number) i hookiem wpinasz link w szablon maila. Brzmi jak robota na pół godziny, ale bez tego zostaje ręczne wklejanie numerów do każdego zamówienia.
Niezależnie od platformy kluczowe jest mapowanie statusów. Kurier zwraca ich kilkanaście, sklep potrzebuje czterech–pięciu. Przykład: „przesyłka nadana” → Wysłane, „wydana do doręczenia” → W drodze, „gotowa do odbioru w punkcie” → Gotowa do odbioru, „doręczona” → Zrealizowane, „zwrot do nadawcy” → Zwrot. Bez tej mapy klient widzi surowy status przewoźnika i dzwoni z pytaniem, co on właściwie oznacza.
Druga rzecz to doświadczenie odbiorcy. Link do śledzenia bywa najczęściej klikanym elementem całego maila transakcyjnego – warto zadbać o to, co zobaczy po jego kliknięciu. Szerzej opisujemy to w materiale o tym, jak wygląda odbiór paczek z punktu widzenia klienta.
| Element | PrestaShop | WooCommerce |
|---|---|---|
| Pole na numer śledzenia | Wbudowane w karcie zamówienia | Brak – wtyczka lub własne pole meta |
| Link do śledzenia | Wzór URL z placeholderem @ w konfiguracji przewoźnika | Wtyczka albo ręczny link w mailu |
| Mail „wysłano” | Szablony w katalogu mails/ | Mail „Zrealizowane zamówienie” plus rozszerzenie |
| Statusy z API kuriera | Wymaga modułu | Wymaga wtyczki lub własnego kodu |
Przed podpisaniem umowy na integrację ustal trzy rzeczy: sposób autoryzacji, kanał zdarzeń i mapę statusów. Reszta to szczegóły, które da się dopisać później.
Autoryzacja. InPost ShipX pracuje na OAuth2: dostajesz client_id i client_secret, wymieniasz je na token Bearer o ograniczonym czasie życia, a po jego wygaśnięciu odświeżasz token albo pobierasz nowy. DPD i DHL mają po kilka osobnych API – nadawanie, tracking, zamawianie kuriera – i w zależności od usługi używa się klucza API w nagłówku albo OAuth. Nie zakładaj, że jedno uwierzytelnienie obsłuży wszystkie endpointy; często trzeba dwóch. Czas życia tokenu i procedura odświeżania różnią się między wersjami API, więc sprawdź je w dokumentacji przewoźnika w dniu startu prac, a nie w opisie z forum sprzed trzech lat.
Najczęstsza pułapka: aplikacja trzyma token w pliku konfiguracyjnym i po cichu przestaje aktualizować statusy, gdy token wygaśnie. Klient nic nie widzi, Ty nic nie widzisz. Potrzebujesz logowania błędów 401 i 403 oraz alertu, który zadziała, zanim zadzwoni klient.
Mapowanie statusów. Kurier zwraca kilkanaście statusów, w tym warianty tej samej sytuacji dla paczkomatu, kuriera i przesyłki pobraniowej. Na poziomie sklepu wystarczy pięć stanów. Uwaga na kolizje nazw – ten sam status bywa zwracany w innym kontekście dla przesyłek krajowych i zagranicznych.
Paczki awizowane i zwroty. „Awizowana” znaczy, że kurier próbował doręczyć i paczka czeka na ponowną próbę lub odbiór w punkcie – to nie jest stan końcowy. Zwrot wymaga osobnego statusu i osobnej akcji w sklepie (kontakt z klientem, ponowna wysyłka), bo automatyczne „Zrealizowane” przy zwrocie zamyka sprawę, która wcale nie jest zamknięta.
| Kryterium | Webhook | Polling |
|---|---|---|
| Kto inicjuje | Kurier wysyła zdarzenie do sklepu | Sklep odpytuje API w pętli |
| Opóźnienie | Sekundy | Zależy od interwału, np. 5–15 min |
| Obciążenie API | Małe | Rośnie wraz z liczbą paczek |
| Główne ryzyko | Ponowienia i weryfikacja nadawcy | Limit 429 i wygasły token |
| Kiedy wybrać | Gdy kurier udostępnia webhooki | Gdy webhooków brak lub potrzebny stan na żądanie |
Pięć rzeczy psuje śledzenie częściej niż wszystko inne. Każda kończy się telefonem do sklepu, którego nikt nie lubi odbierać.
Jak to wykryć: loguj każde zapytanie i każdy webhook (kod HTTP, czas, treść), dodaj alert, gdy żadne zamówienie nie zmieniło statusu przez ponad 6 godzin w dzień roboczy, oraz alert, gdy ponad 2% żądań zwraca błędy 5xx. Raz w tygodniu przejrzyj raport duplikatów zdarzeń.
| Pułapka | Objaw u klienta | Sygnał, który to zdradza |
|---|---|---|
| Cache statusów z długim TTL | Status starszy niż faktyczny stan przesyłki | Ten sam status w bazie i w cache po zmianie w API |
| Brak idempotencji webhooków | Powtórzone maile i wpisy w historii zamówienia | Wiele zdarzeń o tym samym numerze tracking i statusie |
| Brak fallbacku przy awarii API | Mail bez numeru tracking | Kody 5xx i puste pole tracking w bazie |
| Statusy bez mapowania | Zamówienie „wisi” w starym statusie | Status obecny u kuriera, nieobecny na liście sklepu |
| Brak limitu zapytań | Brak aktualizacji u wszystkich klientów naraz | 429 lub 403 z API kuriera |
Lista jest w kolejności, w której faktycznie się to robi. Możesz przekazać ją wykonawcy albo przejść samodzielnie. Zanim zaczniesz, warto wiedzieć, jak [odbiór paczek nigdy nie był tak prosty](https://dropdigital.pl/odbior-paczek-nigdy-nie-byl-tak-prosty) wygląda z perspektywy twojego klienta — to ta sama osoba, która później dzwoni do supportu.
actionValidateOrder. WooCommerce: metoda wysyłki plus woocommerce_order_status_changed — szczegóły hooków znajdziesz w [dokumentacji deweloperskiej PrestaShop](https://devdocs.prestashop-project.org/).Weryfikacja przed produkcją: wyłącz integrację na 24 godziny po teście i sprawdź, czy kolejka nie zapchała się błędami. Dopiero potem włączaj ją dla wszystkich zamówień.
| Krok | Punkt kontrolny w PrestaShop | Punkt kontrolny w WooCommerce |
|---|---|---|
| Konto i klucz API | Konfiguracja modułu przewoźnika | Klucz w aplikacji kuriera lub wtyczce |
| Tworzenie przesyłki | Hook actionValidateOrder | woocommerce_order_status_changed |
| Mapowanie statusów | Zamówienia → Statusy zamówień | Własne statusy zamówień |
| Maile | Szablony w Zamówienia → Statusy | Ustawienia → E-maile |
| Test | Zamówienie testowe + realna paczka | Zamówienie testowe + realna paczka |
Traktowanie limitu 5 paczek z aplikacji kuriera jako limitu sklepu
Jak wykryć: Ktoś w firmie mówi, że sklep nie może obsłużyć więcej niż 5 przesyłek naraz, a jednocześnie limit widać wyłącznie w aplikacji mobilnej lub na stronie przewoźnika.
Jak naprawić: Rozdziel dwa kanały: aplikacja konsumencka (limit widoku) i konto firmowe z API (lista przesyłek bez limitu 5 pozycji). Ustal, z którego kanału faktycznie korzysta zespół.
Ręczne przepisywanie numerów przesyłek z maila kuriera do sklepu
Jak wykryć: W dzienniku pracy widać godziny przeznaczone na kopiowanie numerów, a klienci dostają tracking z kilkugodzinnym opóźnieniem.
Jak naprawić: Pobieraj numery tracking z API albo importuj je zbiorczo z pliku CSV. Przy wysyłce masowej ustaw automatyczne dopisanie numeru do zamówienia.
Brak automatycznych powiadomień o zmianie statusu przesyłki
Jak wykryć: Duża część zgłoszeń do obsługi klienta to pytania typu „gdzie jest moja paczka”, mimo że status jest już dostępny u kuriera.
Jak naprawić: Wysyłaj e-mail lub SMS z numerem i linkiem do śledzenia przy każdej istotnej zmianie statusu, zamiast czekać, aż klient sam zapyta.
Odpytywanie API w pętli co minutę dla każdej przesyłki
Jak wykryć: W logach widać setki identycznych zapytań, pojawiają się odpowiedzi typu 429 lub czasowe blokady dostępu do API.
Jak naprawić: Przejdź na webhooki tam, gdzie kurier je udostępnia. Polling zostaw jako plan B i ustaw go rzadziej, tylko dla przesyłek będących w drodze.
Niepełne mapowanie statusów kuriera na statusy sklepu
Jak wykryć: Zamówienia zostają w statusie „wysłane” mimo zwrotu lub awiza, a klient widzi w sklepie informację sprzeczną z tym, co pokazuje kurier.
Jak naprawić: Zrób tabelę mapowania dla każdego przewoźnika i obsłuż osobno statusy: awizowana, w doręczeniu, doręczona, zwrot. Przetestuj każdy wariant na jednym zamówieniu.
Zignorowanie czasu życia tokenu i braku jego odświeżania
Jak wykryć: Integracja działa zaraz po wdrożeniu, a po kilku godzinach lub dniach przestaje aktualizować statusy. W logach pojawia się błąd autoryzacji.
Jak naprawić: Wdróż zapis tokenu odświeżania i automatyczne odświeżanie przed wygaśnięciem. Dodaj alert, gdy liczba błędów autoryzacji rośnie.
Limit 5 paczek jednocześnie to ograniczenie widoku w aplikacji lub panelu konsumenta, a nie limit sprzedaży ani wysyłki. Sklep z kontem firmowym i integracją API pracuje na liście przesyłek, więc ten konkretny limit go nie dotyczy. Problem pojawia się gdzie indziej: przy ręcznym przepisywaniu numerów, braku webhooków i niepełnym mapowaniu statusów. Sprawdź, z którego kanału korzysta Twój zespół, i dopiero wtedy decyduj, co usprawniać.
Nie. Limit 5 paczek to ograniczenie interfejsu aplikacji lub panelu konsumenta. Sklep korzystający z konta firmowego i API pracuje na liście przesyłek i nie wyświetla ich w takim widoku. Inna sprawa, że sam kurier może ograniczać liczbę zapytań do API — to jednak zupełnie inny mechanizm.
Masz cztery drogi: konto firmowe lub API u kuriera zamiast aplikacji konsumenckiej, webhooki zamiast odpytywania API, tracker zbiorczy z importem numerów z pliku CSV oraz powiadomienia e-mail lub SMS z linkiem do statusu. Wybór zależy od tego, czy jesteś odbiorcą kilku paczek, czy sklepem wysyłającym ich kilkadziesiąt dziennie.
Nie, limity i sposoby dodawania numeru przesyłki różnią się między przewoźnikami i między aplikacją a kontem firmowym. Nie zakładaj, że skoro w jednej aplikacji działa 5 numerów, to u innego kuriera będzie tak samo. Najszybciej sprawdzisz to, dodając kolejne numery i obserwując, kiedy pojawi się komunikat.
Odpytywanie to pytanie kuriera o status w regularnych odstępach — łatwo o setki zbędnych zapytań i trafienie w limit. Webhook to powiadomienie wysłane przez kuriera w momencie zmiany statusu, więc status trafia do sklepu szybciej i przy mniejszym obciążeniu. Jeśli kurier udostępnia webhooki, warto wybrać tę opcję, a odpytywanie zostawić jako zabezpieczenie.
Tak, ale zależy on od planu. Wersje darmowe zwykle pozwalają śledzić ograniczoną liczbę przesyłek w danym okresie, a plany płatne podnoszą ten limit. Przed wyborem narzędzia sprawdź aktualny cennik i warunki, bo zmieniają się one częściej niż dokumentacja API kurierów.
W obu platformach trzeba sprawdzić, co daje wbudowana funkcja, a co wymaga modułu lub wtyczki. Kluczowe jest automatyczne podstawienie numeru przesyłki i linku do śledzenia w treści wiadomości oraz poprawne mapowanie statusów zamówienia na statusy kuriera. Warto zadbać też o stronę, z której klient odbiera paczkę — o tym piszemy w artykule Odbiór paczek nigdy nie był tak prosty.
Sama strona statusu zamówienia zwykle nie buduje pozycji w wyszukiwarce, bo jest widoczna dla jednego klienta. Ma natomiast znaczenie dla doświadczenia zakupowego i liczby pytań do obsługi. Jeśli publikujesz treści wokół tematu dostaw, trzymaj się zasad tworzenia materiałów dla ludzi (https://developers.google.com/search/docs/fundamentals/creating-helpful-content).
Jeśli chcesz, żeby klienci sami sprawdzali status przesyłki, a zespół przestał przeklejać numery tracking z maili, napisz do nas. Przejrzymy to, co masz teraz w PrestaShop, WooCommerce lub w integracjach z kurierami, i podpowiemy, co warto poprawić w pierwszej kolejności.