Amazon-connector voor Odoo: welke credentials SP-API vraagt, welke limieten gelden en wat hij moet dekken

Als je zoekt naar een Amazon Odoo-connector of Amazon SP-API Odoo, is het korte antwoord dit: je hebt drie credentials nodig die niet van dezelfde plek komen (een SP-API-applicatie die is geregistreerd door een ontwikkelaarsprofiel met goedgekeurde rollen, de LWA-sleutels van die applicatie en een refresh token voor elke verkoper die haar autoriseert), plus de marketplace id en het regionale endpoint. En één ontwerpbeslissing: de limieten zijn tokenbuckets per operatie, dus de connector werkt met een wachtrij en backoff, niet met lussen.

Alles hieronder is gecontroleerd op 13 september 2026 in de officiële SP-API-documentatie en in de code van onze eigen Amazon Seller-connector voor Odoo, gepubliceerd op de branches 19.0, 18.0 en 17.0, met 786 eigen tests op die van Odoo 19 en 685 op elk van de andere twee.

Wat een Amazon Odoo-connector moet oplossen

• Betrouwbare orderimport en voorraadreserveringen.
• Mapping van SKU's, varianten en listings zonder duplicaten.
• Synchronisatie van statussen, tracking en bevestigingen.
• Beheer van prijzen, incidenten en foutsituaties.
• Verwerking van FBA wanneer dat deel uitmaakt van de werkwijze.
• Logs en nieuwe pogingen wanneer Amazon of de interne wachtrij faalt.

Elke regel komt binnen via een andere deur (/orders/v0, /listings/2021-08-01, /feeds/2021-06-30, /reports/2021-06-30) en elke deur heeft zijn eigen limiet.

Welke credentials SP-API vraagt en wie ze uitgeeft

1. De applicatie. SP-API opent niet met de gebruiker van Seller Central, maar met een applicatie die in het Solution Provider Portal is geregistreerd door een goedgekeurd ontwikkelaarsprofiel. Bij de registratie kies je rollen (Amazon documenteert er achttien) en je kunt alleen de al goedgekeurde kiezen. Vier zijn beperkt omdat ze persoonsgegevens raken, waaronder Direct-to-Consumer Shipping. En de rol alleen is niet genoeg: het afleveradres vraag je op met een restricted data token (POST /tokens/2021-03-01/restrictedDataToken).

2. De LWA-sleutels. Uit de applicatie komen een client_id en een client_secret van Login with Amazon. Het secret verloopt na 180 dagen: Amazon waarschuwt 90 dagen vooraf en het oude blijft nog zeven dagen geldig. Na die termijn mislukken de aanroepen zonder dat iemand iets heeft aangepast, en het symptoom (invalid_client midden in de nacht) lijkt niet op de oorzaak; daarom bewaart de connector die datum en waarschuwt hij met een dagelijkse cron.

3. Het refresh token van de verkoper. Dit is het enige dat je niet zelf invult: de verkoper genereert het door de app te autoriseren op sellercentral…/apps/authorize/consent, met de application_id en een eigen state; als de app nog een concept is, voeg je &version=beta toe, en bij publicatie moet je dat weghalen. Amazon stuurt het naar je redirect URI met een spapi_oauth_code die je binnen vijf minuten inwisselt op https://api.amazon.com/auth/o2/token: daaruit komen een access_token, dat na een uur verloopt, en het refresh_token.

4. Marketplace en regio. Een account is geen land: het is een marketplace id (Spanje A1RKKUPIHCS9HS, Frankrijk A13V1IB3VIYZZH) die naar een regionaal endpoint wijst, https://sellingpartnerapi-eu.amazon.com in Europa. Onze connector levert de 23 marketplaces als gegevens mee en elk account wijst naar slechts één, zodat voorraad, belastingen en kanaal uit de juiste plek komen.

Limieten: waarom de connector een wachtrij nodig heeft

Amazon verdeelt het verkeer met een tokenbucket: elke operatie heeft een snelheid (tokens per seconde) en een burst (capaciteit), en elk verzoek kost één token. Wanneer de bucket leeg is, komt er een 429, die de documentatie als herhaalbaar bestempelt, en (wanneer beschikbaar, wat niet altijd zo is) komt de header x-amzn-RateLimit-Limit terug met de limiet van jouw combinatie van verkoper en applicatie. De limieten gelden per operatie, en die in de tabel zijn de standaardwaarden, die Amazon kan verhogen voor wie meer volume verwerkt.

Die tabel verklaart het ontwerp. Omdat getOrders op één per minuut zit, worden orders gelezen met een watermerk (LastUpdatedAfter) en paginering via NextToken vanuit een cron elke vijftien minuten, niet met een knop. Omdat je op rapporten moet wachten, is de cyclus aanmaken, pollen en downloaden: we pollen maximaal twaalf keer, elke tien seconden. En omdat rapportaanroepen één bucket delen, schrijft de connector bij een 429 een gedeelde afkoelperiode van 90 seconden weg en valt de FBA-voorraad terug op de live API.

De nieuwe poging zit in één enkele functie: 429 en 500, 502, 503 en 504 worden opnieuw geprobeerd, Retry-After wordt gerespecteerd en, als die ontbreekt, wacht de connector met een exponentiële backoff vanaf 1,5 seconde met willekeurige ruis, zodat twee crons niet tegelijk terugkomen. Als ook de laatste poging mislukt, bevat de fout de Retry-After, de quota-header en het pad: de log zegt welke quota op is, niet "fout bij synchroniseren".

Vandaar de regel: wat schrijft gaat in een wachtrij met een idempotentiesleutel; wat leest gaat met een watermerk. Een zending bevestigen kan in de wachtrij op "in afwachting" blijven staan, en dan is de enige afzender een cron elke vijf minuten die maximaal 200 leveringen van de afgelopen drie dagen oppakt, met een slot per levering dat voorkomt dat dezelfde tracking twee keer wordt verstuurd. Prijzen en voorraad hebben elk hun eigen wachtrij per minuut; als een schrijfactie mislukt, probeert een andere wachtrij het elke 180 seconden opnieuw, maximaal twintig keer per SKU.

Waarom Amazon operaties laat vastlopen wanneer Odoo niet de leiding heeft

Als de voorraad uit meerdere plekken komt of de tracking buiten het ERP wordt beheerd, volgen de incidenten: orders zonder mapping, inconsistente voorraad en duurdere nazorg. Met de limieten voor ogen zie je waarom het kanaal dat de voorraad publiceert er maar één mag zijn: twee keer publiceren kost dubbele quota. We werken het uit in realtime voorraad op marketplaces en in verkopen op meerdere marketplaces vanuit één Odoo.

Veelvoorkomende fouten met Amazon SP-API in Odoo

Bijna alle storingen die we zien komen van die drie credentials, niet van de code: een redirect URI die naar een andere Odoo wijst, waardoor de verkoper na terugkeer op een scherm belandt dat zegt dat niemand hem verwachtte; een autorisatie met version=beta terwijl de app al is gepubliceerd; het verlopen LWA-secret; de beperkte rol die niet is goedgekeurd, wat geen duidelijke fout geeft maar lege adressen; en de 429-lus wanneer iemand handmatig opnieuw probeert terwijl ook de cron opnieuw probeert.

Elk heeft een symptoom dat niet op zijn oorzaak lijkt, dus we hebben ze met hun diagnose verzameld in Amazon SP-API en Odoo: veelvoorkomende fouten en hoe je ze voorkomt. Als jouw vraag de ingebruikname is, staat het stappenplan in hoe je Amazon met Odoo 19 integreert.

Begin met wat het meeste pijn doet

Met de limieten voor ogen is er een verstandige volgorde: eerst orders, voorraad en tracking, de drie aanroepen die het magazijn draaiend houden; daarna listings, prijzen, FBA of retouren als het bedrijf dat vraagt. De rapporten komen als laatste: ze zijn niet moeilijk, maar ze verbruiken de trage quota.

Wat je moet vragen voordat je koopt

• Welke stromen vandaag worden ondersteund en via welke API elk daarvan loopt.
• Of de koppeling jouw applicatie gebruikt of die van de leverancier, en wie het LWA-secret vernieuwt.
• Wat er bij een 429 gebeurt: probeert hij opnieuw, zet hij in de wachtrij, respecteert hij Retry-After, laat hij sporen na?
• Hoe FBA, retouren en adressen met persoonsgegevens worden verwerkt.
• Of de tracking twee keer wordt verstuurd als je dezelfde zending twee keer bevestigt.
• Of de leverancier ook implementeert of alleen een licentie verkoopt, en voor welke versies hij de module onderhoudt.

Als de integratie niet met Amazon is maar met je eigen beheersoftware, is de aanpak dezelfde en die beschrijven we in Odoo-connector voor jouw software; de catalogus staat in modules en de kaart per probleem in oplossingen.

Veelgestelde vragen

Nuttige links binnen FlexigoTech

Wat wij hieraan doen