Konektor Amazon dla Odoo: jakich danych dostępowych wymaga SP-API, jakie ma limity i co musi obejmować

Jeśli szukasz frazy konektor Amazon Odoo lub Amazon SP-API Odoo, krótka odpowiedź brzmi tak: potrzebne są trzy dane dostępowe, które nie pochodzą z jednego miejsca (aplikacja SP-API zarejestrowana przez profil dewelopera z zatwierdzonymi rolami, klucze LWA tej aplikacji oraz refresh token każdego sprzedawcy, który ją autoryzuje), a do tego marketplace id i regionalny endpoint. Oraz jedna decyzja projektowa: limity to wiadra żetonów przypisane do operacji, więc konektor ma kolejkę i backoff, a nie pętle.

Wszystko poniżej sprawdziliśmy 13 września 2026 w oficjalnej dokumentacji SP-API oraz w kodzie naszego Konektora Amazon Seller dla Odoo, opublikowanego w gałęziach 19.0, 18.0 i 17.0, z 786 własnymi testami w wersji dla Odoo 19 i 685 w każdej z dwóch pozostałych.

Co powinien rozwiązywać konektor Amazon Odoo

• Niezawodny import zamówień i rezerwacja zapasów.
• Mapowanie SKU, wariantów i ofert bez duplikatów.
• Synchronizacja statusów, numerów przesyłek i potwierdzeń.
• Obsługa cen, incydentów i przypadków błędów.
• Obsługa FBA, gdy jest częścią operacji.
• Logi i ponowienia, gdy zawiedzie Amazon lub wewnętrzna kolejka.

Każda pozycja wchodzi innymi drzwiami (/orders/v0, /listings/2021-08-01, /feeds/2021-06-30, /reports/2021-06-30) i każde drzwi mają własny limit.

Jakich danych dostępowych wymaga SP-API i kto je wydaje

1. Aplikacja. SP-API nie otwiera się kontem z Seller Central, lecz aplikacją zarejestrowaną w Solution Provider Portal przez zatwierdzony profil dewelopera. Przy rejestracji wybiera się role (Amazon opisuje ich osiemnaście), a dostępne są tylko te już zatwierdzone. Cztery są ograniczone, bo dotyczą danych osobowych, w tym Direct-to-Consumer Shipping. Samo posiadanie roli nie wystarczy: adres dostawy pobiera się za pomocą restricted data token (POST /tokens/2021-03-01/restrictedDataToken).

2. Klucze LWA. Z aplikacji otrzymujesz client_id i client_secret z Login with Amazon. Sekret wygasa po 180 dniach: Amazon ostrzega 90 dni wcześniej, a stary działa jeszcze siedem dni dłużej. Po tym terminie wywołania przestają działać, mimo że nikt niczego nie ruszał, a objaw (invalid_client w nocy) nie przypomina swojej przyczyny; dlatego konektor zapisuje tę datę i ostrzega codziennym cronem.

3. Refresh token sprzedawcy. To jedyna rzecz, której nie wpisujesz Ty: generuje ją sprzedawca, autoryzując aplikację pod adresem sellercentral…/apps/authorize/consent, z application_id i własnym state; jeśli aplikacja jest jeszcze szkicem, dodaje się &version=beta, a po jej opublikowaniu trzeba to usunąć. Amazon zwraca je na Twój redirect URI razem z spapi_oauth_code, który trzeba wymienić w ciągu pięciu minut pod adresem https://api.amazon.com/auth/o2/token: w odpowiedzi dostajesz access_token, który wygasa po godzinie, oraz refresh_token.

4. Marketplace i region. Konto to nie kraj: to marketplace id (Hiszpania A1RKKUPIHCS9HS, Francja A13V1IB3VIYZZH) wskazujący regionalny endpoint, w Europie https://sellingpartnerapi-eu.amazon.com. Nasz konektor zawiera 23 marketplace'y jako dane, a każde konto wskazuje tylko jeden z nich, dzięki czemu zapasy, podatki i kanał pochodzą z właściwego miejsca.

Limity tempa: dlaczego konektor potrzebuje kolejki

Amazon dzieli ruch za pomocą wiadra żetonów: każda operacja ma tempo (żetony na sekundę) i burst (pojemność), a każde żądanie zużywa jeden żeton. Gdy wiadro się opróżni, przychodzi 429, które dokumentacja nazywa nadającym się do ponowienia, oraz (gdy jest dostępny, a nie zawsze jest) wraca nagłówek x-amzn-RateLimit-Limit z limitem dla Twojej pary sprzedawca-aplikacja. Limity są przypisane do operacji, a te z tabeli to wartości domyślne, które Amazon może podnieść tym, którzy obsługują większy wolumen.

Ta tabela wyjaśnia projekt. Ponieważ getOrders działa z tempem jednego na minutę, zamówienia odczytuje się ze znacznikiem postępu (LastUpdatedAfter) i stronicowaniem przez NextToken z crona co piętnaście minut, a nie przyciskiem. Ponieważ na raporty trzeba czekać, cykl to utworzenie, odpytywanie i pobranie: odpytujemy do dwunastu razy co dziesięć sekund. A ponieważ wywołania raportów dzielą jedno wiadro, przy błędzie 429 konektor zapisuje wspólne wstrzymanie na 90 sekund, a zapasy FBA przechodzą na API na żywo.

Ponowienie mieści się w jednej funkcji: błędy 429 oraz 500, 502, 503 i 504 są ponawiane, respektowany jest Retry-After, a gdy go brak, czeka się z wykładniczym backoffem od 1,5 sekundy z losowym szumem, żeby dwa crony nie wróciły jednocześnie. Jeśli ostatnia próba też się nie powiedzie, błąd zawiera Retry-After, nagłówek limitu i ścieżkę: log mówi, który limit się wyczerpał, a nie „błąd synchronizacji”.

Stąd reguła: to, co zapisuje, trafia do kolejki z kluczem idempotencji; to, co odczytuje, działa ze znacznikiem postępu. Potwierdzenie wysyłki może zostać w kolejce jako „oczekujące” i wtedy jedynym nadawcą jest cron co pięć minut, który bierze najwyżej 200 dostaw z ostatnich trzech dni, z blokadą dla każdej dostawy, która nie pozwala wysłać tego samego numeru przesyłki dwa razy. Ceny i zapasy mają własną kolejkę co minutę; jeśli zapis się nie powiedzie, inna kolejka ponawia go co 180 sekund, najwyżej dwadzieścia razy na SKU.

Dlaczego Amazon psuje operacje, gdy nie rządzi Odoo

Jeśli zapasy pochodzą z kilku miejsc albo numery przesyłek obsługuje się poza ERP, pojawiają się incydenty: niezmapowane zamówienia, niespójny magazyn i droższa obsługa posprzedażowa. Przy znajomości limitów widać, dlaczego kanał publikujący zapasy musi być jeden: publikowanie ich dwa razy kosztuje dwa razy tyle limitu. Rozwijamy to w zapasach w czasie rzeczywistym na marketplace'ach i w sprzedaży na wielu marketplace'ach z jednego Odoo.

Częste błędy Amazon SP-API w Odoo

Prawie wszystkie awarie, które widzimy, wynikają z tych trzech danych dostępowych, a nie z kodu: redirect URI wskazujący na inne Odoo, przez co powrót sprzedawcy kończy się ekranem z informacją, że nikt go nie oczekiwał; autoryzacja z version=beta, gdy aplikacja jest już opublikowana; wygasły sekret LWA; niezatwierdzona rola ograniczona, która nie daje czytelnego błędu, tylko puste adresy; oraz pętla błędów 429, gdy ktoś ponawia ręcznie, podczas gdy ponawia też cron.

Każdy z nich ma objaw niepodobny do swojej przyczyny, dlatego zebraliśmy je razem z diagnozą w Amazon SP-API i Odoo: częste błędy i jak ich uniknąć. Jeśli Twoja sprawa to uruchomienie, przebieg opisuje jak zintegrować Amazon z Odoo 19.

Zacznij od tego, co boli najbardziej

Przy znajomości limitów jest rozsądna kolejność: najpierw zamówienia, zapasy i numery przesyłek, czyli trzy wywołania, na których opiera się magazyn; potem oferty, ceny, FBA lub zwroty, jeśli biznes tego potrzebuje. Raporty na końcu: nie są trudne, ale zużywają wolny limit.

O co zapytać przed zakupem

• Które przepływy są dziś obsługiwane i przez jakie API wchodzi każdy z nich.
• Czy połączenie używa Twojej aplikacji, czy aplikacji dostawcy, i kto rotuje sekret LWA.
• Co dzieje się przy błędzie 429: czy ponawia, kolejkuje, respektuje Retry-After, zostawia ślad?
• Jak traktowane są FBA, zwroty i adresy z danymi osobowymi.
• Czy dwukrotne potwierdzenie tej samej wysyłki powoduje dwukrotne wysłanie numeru przesyłki.
• Czy dostawca wdraża, czy tylko sprzedaje licencję, i w jakich wersjach utrzymuje moduł.

Jeśli integracja nie dotyczy Amazon, lecz Twojego własnego programu do zarządzania, założenia są te same i opisujemy je w konektorze Odoo dla Twojego oprogramowania; katalog jest w modułach, a mapa według problemu w rozwiązaniach.

Najczęstsze pytania

Przydatne linki w FlexigoTech

Co robimy w tym zakresie