SP-API Amazona z perspektywy Odoo: co autoryzujesz, co Cię ogranicza i co zawodzi dopiero na produkcji

SP-API to skrót od Selling Partner API: interfejsu, przez który Amazon pozwala zewnętrznemu programowi odczytywać i zapisywać dane na Twoim koncie Seller Central. Zastąpił MWS i zmienił znacznie więcej niż samą nazwę. Od strony Odoo samo API jest najłatwiejszą częścią: to żądania HTTP z JSON. O tym, czy integracja przetrwa listopad, decydują trzy rzeczy, których nie zobaczysz w dokumentacji pojedynczego endpointu: jak się ją autoryzuje, ile wywołań Ci pozwolą wykonać i które dane z założenia docierają z opóźnieniem.

Autoryzację podpisuje się w Seller Central, nie w Odoo

Przepływ jest zawsze taki sam: istnieje aplikacja zarejestrowana w profilu dewelopera, a Ty, jako sprzedawca, autoryzujesz ją ze swojego konta. Z tej autoryzacji powstaje długotrwały refresh token, który Odoo przechowuje; za jego pomocą, gdy tylko potrzebuje, prosi o token dostępu ważny przez godzinę. Jeśli ktoś prosi o Twoje dane logowania do Seller Central, żeby „to skonfigurować”, coś jest nie tak: nikt nie potrzebuje Twojego hasła do tego celu. A jeśli cofniesz autoryzację, integracja natychmiast się zatrzymuje, i tak właśnie ma być.

Dane kupującego idą osobnym wejściem

Imię i nazwisko, adres i telefon kupującego to dane osobowe i Amazon traktuje je jako takie: nie przychodzą w zwykłej odpowiedzi dotyczącej zamówienia. Trzeba poprosić o token z ograniczeniami dla tego konkretnego zapytania, a uprawnienie do tego przyznawane jest według roli, nie domyślnie. Praktyczna konsekwencja w Odoo: zamówienia mogą importować się bez zarzutu, a dostawy nie da się wysłać, bo brakuje adresu. To nie błąd konektora; to uprawnienie, które nie zostało zatwierdzone.

Limity wywołań to budżet, nie prędkość

Każda operacja SP-API ma własny limit i działa jak zbiornik, który napełnia się ze stałą szybkością i dopuszcza krótki zryw ponad ten poziom. Dopóki jest zapas, działasz szybko; gdy się wyczerpie, Amazon odpowiada 429 i trzeba czekać. Dla Odoo ma to bezpośrednie znaczenie: nie można przejść przez 4 000 referencji, wywołując je pojedynczo, „bo tak jest prościej”. Trzeba grupować, respektować nagłówek limitu zwracany przez samo API i ponawiać próby z rosnącym opóźnieniem. I trzeba, żeby synchronizacja ręczna i cron miały wspólny hamulec, bo budżet dotyczy całego konta, a nie każdego procesu osobno.

Raporty a wywołania na żywo: dlaczego Twój stan magazynowy zawsze się spóźnia

SP-API daje dane na dwa sposoby. Pierwszy to wywołanie bezpośrednie: pytasz o zamówienia od danej daty i dostajesz odpowiedź od razu. Drugi to system raportów, który jest asynchroniczny: zlecasz raport, Amazon przygotowuje go, kiedy może, Ty sprawdzasz, czy jest gotowy, a potem pobierasz skompresowany plik. Tą drogą idą stany magazynowe FBA i rozliczenia. Oznacza to, że stan, który widzisz w Odoo, pochodzi z ostatniego pobrania, a nie z tej sekundy, i żadna częstotliwość crona tego nie naprawi. Właściwa odpowiedź to nie częstsze wywołania, lecz publikowanie z buforem bezpieczeństwa i pogodzenie się z opóźnieniem.

Błędy, które pojawiają się tylko na produkcji

Są zawsze te same i żaden nie pojawia się pierwszego dnia. Zamówienia w stanie oczekującym, które przychodzą bez kwot i adresu i trzeba je odczytać ponownie później. Paginacja: pierwsza strona wchodzi, a reszta ginie, jeśli nikt nie podąży za tokenem kontynuacji. Okna dat źle wyliczone przez strefę czasową, które zostawiają lukę w zamówieniach dokładnie na przełomie dnia. Tokeny, które wygasają w trakcie długiej synchronizacji i trzeba je odnowić w locie. I zły region: aplikacja jest globalna, ale konto sprzedawcy nie, a zapytanie o zamówienia z Niemiec do endpointu Ameryki Północnej nie odpowie „zły region”, tylko „Access to requested resource is denied”. Wygląda to na problem z uprawnieniami, więc regeneruje się poświadczenia, które były w porządku, podczas gdy błąd tkwi w adresie URL.

Gdzie to musi żyć w Odoo

Wywołanie do Amazona nie może wisieć na zatwierdzeniu dostawy. Jeśli API działa wolno, użytkownik patrzy na kółko ładowania, a jeśli zawiedzie, traci wykonaną pracę. Miejscem na te wywołania jest zaplanowane działanie lub kolejka zadań, z ponawianiem prób, rejestrem tego, o co zapytano i co odpowiedział Amazon, oraz z operacjami idempotentnymi: powtórzenie synchronizacji nie może utworzyć zamówienia dwa razy. Ten rejestr pozwala potem rozmawiać z pomocą techniczną Amazona na podstawie danych, a nie wrażeń. Resztę wzorca, zastosowaną do zamówień, które się nie pojawiają, znajdziesz w dlaczego zamówienia z Amazona nie trafiają do Odoo.

Kiedy nie musisz niczego budować

Jeśli sprzedajesz na jednym marketplace, z niewielką liczbą referencji, i potrzebujesz tylko, żeby zamówienia wpadały do systemu, może Ci wystarczyć konektor Amazona, który Odoo Enterprise ma w standardzie. Warto go wypróbować, zanim za cokolwiek zapłacisz. Rozmowa się zmienia, gdy pojawia się kilka krajów z własnymi podatkami, zapasy współdzielone z innymi kanałami, rozliczenia do uzgodnienia albo potwierdzenia wysyłki z terminem. Tu pracę wykonuje nasz konektor Amazona dla Odoo: SP-API z kontrolą limitów, raporty, FBA i FBM, w Odoo 17, 18, 19 i 20.

Najczęstsze pytania

Przydatne linki w FlexigoTech

Co robimy w tej sprawie