Połączenie API Temu z Odoo: o co się prosi, co się odczytuje i co się zapisuje

„Czy Temu ma API?” Tak. Przydatne jest inne pytanie: o co trzeba poprosić, żeby z niego korzystać, co można odczytać, co można zapisać i co się dzieje, gdy odpowiada odmową. Te cztery odpowiedzi decydują, czy integracja wytrzyma szczyt zamówień, czy padnie w pierwszy piątek wyprzedaży. Po kolei.

Dane uwierzytelniające to nie login i hasło

Temu działa jak każdy poważny marketplace: jest zarejestrowana aplikacja z kluczem i sekretem oraz autoryzacja, którą sklep udziela tej aplikacji. Z tego powstaje token, który wygasa, a integracja musi wiedzieć kiedy, i z wyprzedzeniem ostrzec, by odnowić autoryzację, zanim straci ważność. W Odoo oznacza to, że token znajduje się w parametrze systemowym z uprawnieniami, a nie w polu tekstowym, które ktoś kiedyś wkleił i nikt już o nim nie pamięta. Oznacza też, że w dniu, w którym sklep cofnie autoryzację, synchronizacja ma zatrzymać się i dać znać, a nie przez tydzień po cichu zwracać błędy.

Jakich rodzin endpointów naprawdę potrzeba

Dokładne nazwy zmieniają się między wersjami API; rodziny nie, a jest ich pięć. Lista zamówień według przedziału czasu, by pobierać tylko nowe, bez żądania całej historii. Szczegóły zamówienia, gdzie znajdują się pozycje, wariant, kwoty i podatki. Potwierdzenie wysyłki, z przewoźnikiem i numerem przesyłki, czyli jedyna rzecz, na podstawie której Temu uznaje zamówienie za zrealizowane. Katalog, do publikowania i aktualizowania kart produktów. Oraz stany magazynowe, osobno od katalogu, bo zmieniają się tysiące razy częściej. Jeśli integracja obejmuje tylko dwie pierwsze, to nie jest integracja, tylko importer.

Szczegóły każdej rodziny omawiamy w dwóch artykułach siostrzanych: importowanie zamówień bez utraty danych i synchronizacja produktów i cen.

Stan magazynowy to najczęściej powtarzane wywołanie

Sklep z 2 000 referencji, który co piętnaście minut wysyła ponownie cały stan, wykonuje 192 000 zapisów dziennie, żeby zmienić, w najlepszym razie, dwieście wartości. To nie jest synchronizacja, tylko marnowanie limitu. Właściwie jest wysyłać tylko to, co zmieniło się od ostatniej wysyłki, grupując w paczki, a dodatkowo uruchamiać natychmiastową aktualizację, gdy sprzedaż zostawia referencję na granicy zera. Wysoka częstotliwość nie zapobiega nadsprzedaży; zapobiega jej bufor bezpieczeństwa.

Limity: API to nie baza danych, którą można odpytywać do woli

Każde API marketplace ma pułap wywołań w danym oknie czasowym i prędzej czy później na niego trafisz. O tym, czy integracja jest zdrowa, czy zepsuta, decyduje to, co robi po jego osiągnięciu. Odrzucenie z powodu nadmiaru wywołań nie jest błędem, który się połyka i zapomina: to polecenie, by poczekać. Integracja powinna ponawiać próby ze wzrastającym odstępem, kolejkować to, co się nie zmieściło, i podjąć to w następnym cyklu bez duplikowania czegokolwiek. Wszystko to powinno działać w kolejce zadań, a nie w pętli wewnątrz crona. Gdy ta kolejka się zacina, objaw jest taki, jaki opisujemy w zablokowanych kolejkach w Odoo.

Rejestrowanie każdego wywołania to nie paranoja: to jedyny dowód

Gdy zamówienie się nie pojawia albo Temu twierdzi, że nie dostało numeru przesyłki, spór wygrywa się dzięki rejestrowi albo wcale. Dla każdego wywołania trzeba zapisać: dokładny moment, endpoint, wysłaną treść, kod i otrzymaną odpowiedź oraz identyfikator zamówienia lub dotyczącą go referencję. Bez sekretów i tokenów jawnym tekstem, z rozsądnym okresem przechowywania, żeby tabela nie zjadła dysku. To pierwsza rzecz, na którą patrzymy podczas audytu konektora napisanego przez kogoś innego, a jej brak jest przyczyną połowy przypadków, których nie da się zdiagnozować, jak te opisane w częstych błędach w pracy z API marketplace.

Co robi nasz konektor (a czego nie)

Konektor Temu dla Odoo obejmuje pięć rodzin: importuje zamówienia według przedziału czasu, potwierdza wysyłki z przewoźnikiem i numerem przesyłki, publikuje produkty i SKU oraz wysyła stany magazynowe według SKU, pogrupowane według artykułu. Sklep autoryzuje się kodem wydawanym przez Temu, a konektor zapisuje, kiedy token wygasa, i pokazuje, czy połączenie nadal działa. Synchronizuje przez cron i przez webhook, zapisuje żądanie i odpowiedź każdego potwierdzenia wysyłki oraz treść każdego odebranego webhooka, a jeśli Temu podniesie wersję metody, powtarza wywołanie w nowej wersji.

Czego dziś nie robi, mówiąc wprost: nie wysyła tylko zmienionych stanów, bo przy każdym przebiegu wysyła stany wszystkich powiązanych referencji; nie ma kolejki zadań ze wzrastającym odstępem i nie rejestruje wszystkich wywołań. Odrzucenie z powodu limitu trafia do logu serwera i jest ponawiane przy następnym przebiegu crona. Działa w Odoo 17, 18 i 19. Jeśli zastanawiasz się, czy lepsze jest to, czy middleware nad nim, porównanie znajdziesz w middleware czy natywny konektor: są przypadki, w których właściwa odpowiedź to nie my.

Najczęstsze pytania

Przydatne linki w FlexigoTech

Co robimy w tym zakresie