Integracja sklepu rzadko pada z hukiem. Częściej działa lokalnie, przechodzi pierwsze testy, a po tygodniach zaczyna gubić produkty, duplikować zamówienia albo milczeć w cronie. Winne zwykle nie jest jedno „zepsute API", tylko limity, tokeny, paginacja i retry bez idempotencji. Poniżej: katalog awarii Allegro, WooCommerce i Shopera z liczbami oraz procedura diagnozy. Stan sprawdzony 03.09.2026.
Sześć awarii, które wracają najczęściej
| Objaw | Prawdopodobna przyczyna | Dowód, który potwierdza |
|---|---|---|
| Seria 429 w południe | Przekroczony limit zapytań na Client ID | Kod 429 w logu o pełnych godzinach, cisza w nocy |
| Integracja zwalnia, potem staje | Natychmiastowe ponawianie po 429 zamiast backoffu | Serie 429 bez przerw, rosnąca kolejka |
| Część katalogu nie trafia do sklepu | Pętla paginacji kończy się po pierwszej stronie | Oczekiwano X, pobrano Y mniejsze od X |
| Duplikaty zamówień w ERP | Retry po timeoucie bez klucza idempotencji | Dwa dokumenty, jeden identyfikator operacji |
| Proces działa lokalnie, nie działa w cronie | Token niewidoczny dla użytkownika crona | Kod 401 tylko w logu crona |
| Webhook przestał przychodzić | Pięć kolejnych nieudanych doręczeń wyłączyło subskrypcję | Status disabled w panelu lub API |
Zasada diagnostyczna: najpierw dowód, potem kod. Poprawianie przed zebraniem dowodu kończy się drugą poprawką tego samego miejsca (onetaptosite.pl, 28.07.2026).
Limity w liczbach: Allegro
Allegro nakłada główny limit 9000 zapytań na minutę na Client ID, taki sam na produkcji i na środowisku testowym. Po przekroczeniu Client ID ląduje w blokadzie na minutę, a odpowiedzi wracają z kodem 429 Too Many Requests (developer.allegro.pl, poradniki o limitach). Równolegle możesz mieć otwartych 20 sesji. Dla wybranych zasobów działa dodatkowy mechanizm Leaky Bucket liczony per użytkownik: najpierw serwer wydłuża czas odpowiedzi, przy zbyt wielu równoległych zapytaniach odpowiada 429.
Na to nakładają się limity per endpoint. Pobieranie pojedynczej oferty ma limit 3500 zapytań na minutę, a jej edycja 2500 na minutę, liczone na sprzedawcę, nie na aplikację (ogłoszenie Allegro z 22.10.2024; issue allegro-api #9983, 27.09.2024). W praktyce najboleśniejszy jest endpoint wyszukiwania produktów, limitowany Leaky Bucket do około jednego zapytania na sekundę: sprzedawca z ponad 90 tysiącami ofert nie był w stanie odświeżyć ich raz dziennie, a zespół Allegro odmówił podniesienia limitu decyzją biznesową (issue #11405, 28.04.2025). Dodatkowe limity liczone są na endpoint, nie na grupę (dyskusja w issue #13034, luty 2026). Dla aplikacji SaaS limit jest wspólny na Client ID; osobne rejestracje aplikacji przez użytkowników są zabronione, a realna ścieżka większych limitów wiedzie przez program Certyfikowanego Integratora przy udokumentowanej potrzebie i zoptymalizowanym kodzie (komentarz zespołu Allegro, 10.02.2026).
Shoper i WooCommerce: tokeny, paginacja, webhooks
W Shoperze błąd 429 też nie jest sygnałem do natychmiastowego ponawiania. Odpowiedź zawiera nagłówki limitu i Retry-After: integracja ma zwolnić, wykonać retry po wskazanym czasie i trzymać kontrolowaną współbieżność z górnym limitem prób oraz osobną kolejką błędów (onetaptosite.pl, 28.07.2026). Konkretne wartości limitów zmieniają się z wersjami API (np. wydanie 2026.1 z nowymi endpointami; netplace.com.pl, 07.03.2026), więc żadnej liczby nie traktuj jako gwarantowanej na zawsze i sprawdzaj aktualną dokumentację. Status platformy też bywa przyczyną: w 2026 roku Shoper notował m.in. częściową niedostępność sklepów 17.08.2026 oraz opóźnienia synchronizacji statusów zamówień 05-06.02.2026 (status.shoper.pl).
Najpodlejsze są awarie ciche. Klasyk to token: pierwsze wywołanie testowe przechodzi, a proces w cronie pada po czasie na 401, bo token wygasł, odświeżenie idzie innym klientem OAuth albo sekret leży w miejscu niewidocznym dla użytkownika crona. Drugi klasyk to paginacja: integracja pobiera pierwszą stronę wyników i kończy pętlę, więc część katalogu nigdy nie trafia do sklepu. Trzeci to mapowanie identyfikatorów: API operuje własnymi ID rekordów, a próba użycia SKU w polu na wewnętrzne ID kończy się błędem albo aktualizacją niewłaściwego rekordu. W logu po każdej partii zapisuj trzy liczby: oczekiwano, pobrano i unikalnych. Trzy różne wartości od razu pokazują, czy problem jest w pętli, czy w duplikatach.
W WooCommerce webhooks dostarcza wp-cron przez HTTP POST, a po pięciu kolejnych nieudanych doręczeniach (brak odpowiedzi 2xx) subskrypcja przechodzi w stan disabled i trzeba ją włączyć ponownie przez API (developer.woocommerce.com, dokumentacja webhooks). Operacje zbiorcze mają limit 100 obiektów na wywołanie. Logi doręczeń są dostępne przez API, więc ciszę webhooka diagnozujesz tak samo jak błąd: po identyfikatorze partii i kodach odpowiedzi, nie po domysłach.
Procedura diagnozy w sześciu krokach
Krok 1: Ustal operację i przedział czasu. Bez identyfikatora partii i okna czasowego diagnoza to zgadywanie. Zapisz, która synchronizacja (stany, ceny, zamówienia) i kiedy padła.
Krok 2: Sprawdź token i kody HTTP. 401 tylko w cronie to problem magazynu tokenu, nie logiki. 429 seriami to tempo i brak backoffu, nie „chwilowa awaria".
Krok 3: Porównaj liczby. Oczekiwano X, pobrano Y, unikalnych Z. Y mniejsze od X to paginacja albo filtr. Z mniejsze od Y to duplikaty z retry bez idempotencji.
Krok 4: Odtwórz jeden błędny rekord. Weź konkretny produkt lub zamówienie i przejdź nim całą ścieżkę: payload przed mapowaniem, payload po mapowaniu, odpowiedź API. Porównaj typy pól, słowniki i model brutto versus netto.
Krok 5: Zweryfikuj mapę identyfikatorów. Sprawdź, czy SKU, EAN, ID Shopera i ID systemu zewnętrznego mapują się trwale w obie strony. Jednorazowe dopasowanie „na oko" przy imporcie to proszenie się o nadpisanie cudzego rekordu.
Krok 6: Dopiero teraz poprawiaj. Kolejka z limitem współbieżności, odczyt Retry-After, backoff z górnym limitem prób, klucz idempotencji dla operacji tworzących oraz alert na ciszę (proces nie uruchomił się wcale), nie tylko na błąd. W logach trzymaj identyfikatory, statusy i kody, nigdy pełne tokeny (onetaptosite.pl, 28.07.2026).
Uczciwie: kiedy integracja przez API to zły pomysł
Nie każdy sklep potrzebuje autorskiej integracji. Przy kilkudziesięciu zamówieniach tygodniowo i stabilnym asortymencie tańszy bywa gotowy konektor platformy albo eksport plików o stałej porze. Autorskie połączenie z kolejką, retry i monitoringiem zwraca się, gdy wolumen przekracza możliwości ręcznej kontroli, gdy ceny i stany zmieniają się kilka razy dziennie albo gdy jeden błąd synchronizacji kosztuje więcej niż dzień pracy integratora. Poniżej tego progu integracja to hobby, nie inwestycja.
Co dalej
Jeśli Twoja integracja łapie 429 albo gubi rekordy, zacznij od kroku 3: trzech liczb z ostatniego przebiegu. Dopiero one mówią, czy leczysz tempo, paginację, czy duplikaty. [UZUPEŁNIJ-LINK-KONSULTACJI]
Dokładne bieżące limity Shopera per endpoint i zachowanie nagłówków Retry-After w Twojej wersji API - DO POTWIERDZENIA (metoda: aktualna dokumentacja developers-newprod.shoper.pl plus testowe wywołanie mierzące odpowiedź 429 przed publikacją artykułu). Pisownia endpointów i limitów Allegro dla Twojego konta (Client ID, DCR, program partnerski) - DO POTWIERDZENIA (metoda: dokumentacja developer.allegro.pl i panel dewelopera przed publikacją).