De SP-API van Amazon vanuit Odoo gezien: wat je autoriseert, wat je beperkt en wat alleen in productie misgaat

SP-API staat voor Selling Partner API: de interface waarmee Amazon een extern programma laat lezen en schrijven in je Seller Central-account. Ze verving MWS en veranderde aanzienlijk meer dan alleen de naam. Vanuit Odoo is de API zelf het makkelijke deel: HTTP-verzoeken met JSON. Of de integratie een november overleeft, hangt af van drie zaken die je niet ziet in de documentatie van één endpoint: hoe er wordt geautoriseerd, hoeveel aanroepen je mag doen en welke gegevens bewust te laat binnenkomen.

De autorisatie onderteken je in Seller Central, niet in Odoo

De werking is altijd dezelfde: er bestaat een applicatie die geregistreerd is onder een ontwikkelaarsprofiel, en jij autoriseert haar als verkoper vanuit je eigen account. Uit die autorisatie komt een refresh token met lange looptijd dat Odoo bewaart. Daarmee vraagt Odoo telkens wanneer nodig een toegangstoken aan dat een uur geldig is. Als iemand je inloggegevens van Seller Central vraagt om het "te configureren", klopt er iets niet: niemand heeft je wachtwoord hiervoor nodig. En als je de autorisatie intrekt, stopt de integratie meteen, en dat is precies wat moet gebeuren.

De gegevens van de koper lopen via een aparte deur

Naam, adres en telefoonnummer van de koper zijn persoonsgegevens en Amazon behandelt ze ook zo: ze zitten niet in het gewone antwoord op een bestelling. Voor die specifieke opvraging moet je een beperkt token aanvragen, en de toestemming daarvoor wordt per rol verleend, niet standaard. Praktisch gevolg in Odoo: bestellingen kunnen perfect binnenkomen terwijl leveringen niet verzonden kunnen worden omdat het adres ontbreekt. Dat is geen fout van de connector; het is een toestemming die niet is goedgekeurd.

Limieten voor aanroepen zijn een budget, geen snelheid

Elke operatie van de SP-API heeft zijn eigen limiet en werkt als een reservoir dat in een vast tempo wordt aangevuld en een korte piek erboven toestaat. Zolang er saldo is, ga je snel; als het op is, antwoordt Amazon met 429 en moet je wachten. Dat heeft een directe consequentie voor Odoo: je kunt niet 4.000 referenties een voor een aanroepen "omdat dat eenvoudiger is". Je moet groeperen, de limietheader respecteren die de API zelf teruggeeft en opnieuw proberen met oplopende wachttijd. Ook moeten de handmatige synchronisatie en de cron dezelfde rem delen, want het budget geldt voor het hele account, niet per proces.

Rapporten versus live aanroepen: waarom je voorraad altijd achterloopt

De SP-API geeft je op twee manieren gegevens. De ene is de directe aanroep: je vraagt bestellingen op vanaf een datum en je krijgt meteen antwoord. De andere is het rapportsysteem, dat asynchroon werkt: je vraagt een rapport aan, Amazon maakt het klaar wanneer het kan, jij controleert of het er al is en daarna download je een gecomprimeerd bestand. De FBA-voorraad en de afrekeningen lopen via die weg. Dat betekent dat de voorraad die je in Odoo ziet die van de laatste download is, niet die van dit moment, en geen enkele cronfrequentie verandert dat. Het juiste antwoord is niet vaker aanroepen: het is publiceren met een veiligheidsbuffer en de vertraging accepteren.

De fouten die alleen in productie optreden

Het zijn altijd dezelfde en geen enkele verschijnt op dag één. Bestellingen met de status in afwachting die zonder bedragen en adres binnenkomen en later opnieuw gelezen moeten worden. Paginering: de eerste pagina komt binnen en de rest gaat verloren als niemand het vervolgtoken volgt. Datumvensters die door de tijdzone verkeerd berekend zijn en precies bij de dagwisseling een gat in de bestellingen laten vallen. Tokens die tijdens een lange synchronisatie verlopen en halverwege vernieuwd moeten worden. En de verkeerde regio: de applicatie is wereldwijd, het verkopersaccount niet, en als je de bestellingen van Duitsland opvraagt bij het endpoint van Noord-Amerika, antwoordt het niet "verkeerde regio" maar "Access to requested resource is denied". Het lijkt een rechtenprobleem, dus worden inloggegevens die in orde waren opnieuw aangemaakt terwijl de fout in de URL zit.

Waar dit binnen Odoo moet draaien

Een aanroep naar Amazon mag niet hangen aan de validatie van een levering. Als de API traag is, blijft de gebruiker naar een draaiend wiel staren, en als ze faalt, gaat het gedane werk verloren. De plek voor deze aanroepen is een geplande actie of een takenwachtrij, met opnieuw proberen, een logboek van wat is gevraagd en wat Amazon heeft geantwoord, en idempotente operaties: een synchronisatie herhalen mag de bestelling niet twee keer aanmaken. Dat logboek laat je later met de support van Amazon discussiëren met gegevens in plaats van met indrukken. De rest van het patroon, toegepast op bestellingen die niet verschijnen, staat in waarom Amazon-bestellingen niet in Odoo binnenkomen.

Wanneer je niets hoeft te bouwen

Als je op één marketplace verkoopt, met weinig referenties, en je alleen wilt dat de bestellingen binnenkomen, kan de Amazon-connector die standaard in Odoo Enterprise zit volstaan. Het loont om die eerst uit te proberen voordat je ergens voor betaalt. Het gesprek verandert zodra er meerdere landen met hun eigen btw zijn, voorraad die met andere kanalen wordt gedeeld, afrekeningen die moeten sluiten of verzendbevestigingen met een deadline. Daar doet onze Amazon-connector voor Odoo het werk: SP-API met controle op limieten, rapporten, FBA en FBM, op Odoo 17, 18, 19 en 20.

Veelgestelde vragen

Handige links binnen FlexigoTech

Wat wij hieraan doen