Connector d'Amazon per a Odoo: quines credencials demana SP-API, quins límits de taxa té i què ha de cobrir

Si busques connector Amazon Odoo o Amazon SP-API Odoo, la resposta curta és aquesta: calen tres credencials que no les dona el mateix lloc (una aplicació SP-API registrada per un perfil de desenvolupador amb els rols aprovats, unes claus LWA d'aquesta aplicació i un refresh token per cada venedor que l'autoritza), a més del marketplace id i l'endpoint regional. I una decisió de disseny: els límits són cubs de fitxes per operació, així que el connector porta cua i backoff, no bucles.

Tot el que segueix està comprovat el 13 de setembre de 2026 a la documentació de SP-API i al codi del nostre Connector Amazon Seller per a Odoo, publicat a les branques 19.0, 18.0 i 17.0, amb 786 proves pròpies a la d'Odoo 19 i 685 a cadascuna de les altres dues.

Què ha de resoldre un connector Amazon Odoo

• Importació fiable de comandes i reserves d'estoc.
• Mapatge de SKU, variants i listings sense duplicats.
• Sincronització d'estats, tracking i confirmacions.
• Gestió de preus, incidències i casos d'error.
• Tractament de FBA quan forma part de l'operativa.
• Logs i reintents quan falla Amazon o la cua interna.

Cada línia entra per una porta diferent (/orders/v0, /listings/2021-08-01, /feeds/2021-06-30, /reports/2021-06-30) i cada porta té el seu propi límit.

Quines credencials demana SP-API i qui les dona

1. L'aplicació. SP-API no s'obre amb l'usuari de Seller Central, sinó amb una aplicació registrada al Solution Provider Portal per un perfil de desenvolupador aprovat. En registrar-la es trien rols (Amazon en documenta divuit) i només pots triar els ja aprovats. Quatre són restringits per tocar dades personals, entre ells Direct-to-Consumer Shipping. I tenir el rol no n'hi ha prou: l'adreça de lliurament es demana amb un restricted data token (POST /tokens/2021-03-01/restrictedDataToken).

2. Les claus LWA. De l'aplicació surten un client_id i un client_secret de Login with Amazon. El secret caduca als 180 dies: Amazon avisa 90 dies abans i el vell aguanta set dies més. Passat el termini les crides fallen sense que ningú hagi tocat res, i el símptoma (invalid_client de matinada) no s'assembla a la seva causa; per això el connector guarda aquesta data i avisa amb un cron diari.

3. El refresh token del venedor. És l'únic que no omples tu: el genera el venedor autoritzant l'app a sellercentral…/apps/authorize/consent, amb el application_id i un state propi; si l'app encara és en esborrany s'afegeix &version=beta, i en publicar-la cal treure'l. Amazon el torna al teu redirect URI amb un spapi_oauth_code que es canvia en menys de cinc minuts a https://api.amazon.com/auth/o2/token: d'aquí surten un access_token, que caduca en una hora, i el refresh_token.

4. Marketplace i regió. Un compte no és un país: és un marketplace id (Espanya A1RKKUPIHCS9HS, França A13V1IB3VIYZZH) apuntant a un endpoint regional, https://sellingpartnerapi-eu.amazon.com a Europa. El nostre connector porta els 23 marketplaces com a dades i cada compte apunta a un de sol, perquè estoc, impostos i canal surtin del lloc correcte.

Límits de taxa: per què el connector necessita cua

Amazon reparteix el trànsit amb un cub de fitxes: cada operació té una taxa (fitxes per segon) i un burst (capacitat), i cada petició gasta una fitxa. Quan el cub es buida arriba un 429, que la documentació anomena reintentable, i (quan està disponible, que no sempre) torna la capçalera x-amzn-RateLimit-Limit amb el límit del teu parell venedor-aplicació. Els límits són per operació, i els de la taula són els valors per defecte, que Amazon pot pujar a qui mou més volum.

Aquesta taula explica el disseny. Com que getOrders va a un minut, les comandes es llegeixen amb marca d'aigua (LastUpdatedAfter) i paginació per NextToken des d'un cron cada quinze minuts, no amb un botó. Com que els informes cal esperar-los, el cicle és crear, sondejar i descarregar: sondegem fins a dotze vegades cada deu segons. I com que les crides d'informes comparteixen cub, davant d'un 429 el connector escriu un refredament compartit de 90 segons i l'inventari FBA cau a l'API en viu.

El reintent viu en una sola funció: 429 i 500, 502, 503 i 504 es reintenten, es respecta Retry-After i, si no ve, s'espera un backoff exponencial des d'1,5 segons amb soroll aleatori perquè dos crons no tornin alhora. Si l'últim intent també falla, l'error porta a dins el Retry-After, la capçalera de quota i la ruta: el log diu quina quota s'ha esgotat, no «error en sincronitzar».

D'aquí la regla: el que escriu va en cua amb clau d'idempotència; el que llegeix va amb marca d'aigua. Confirmar l'enviament pot quedar encuat en «pendent» i llavors l'única que envia és un cron cada cinc minuts que agafa com a màxim 200 albarans dels últims tres dies, amb un forrellat per albarà que impedeix enviar el mateix tracking dues vegades. Preus i estoc tenen la seva pròpia cua cada minut; si una escriptura falla, una altra cua la reintenta cada 180 segons, vint vegades com a molt per SKU.

Per què Amazon trenca operacions quan no mana Odoo

Si l'estoc surt de diversos llocs o el tracking es gestiona fora de l'ERP, arriben les incidències: comandes sense mapar, inventari incoherent i postvenda més cara. Amb els límits al davant es veu per què el canal que publica l'estoc ha de ser un de sol: publicar-lo dues vegades costa el doble de quota. Ho desenvolupem a estoc en temps real a marketplaces i a vendre en diversos marketplaces des d'un sol Odoo.

Errors freqüents d'Amazon SP-API a Odoo

Gairebé tots els errors que veiem vénen d'aquestes tres credencials, no del codi: un redirect URI que apunta a un altre Odoo i la tornada del venedor acaba en una pantalla que diu que ningú l'esperava; una autorització amb version=beta quan l'app ja està publicada; el secret LWA caducat; el rol restringit sense aprovar, que no dona error clar sinó adreces buides; i el bucle de 429 quan algú reintenta a mà mentre el cron també reintenta.

Cadascun té un símptoma que no s'assembla a la seva causa, així que els reunim amb el seu diagnòstic a Amazon SP-API i Odoo: errors freqüents i com evitar-los. Si el teu cas és la posada en marxa, el recorregut és a com integrar Amazon amb Odoo 19.

Comença pel que més fa mal

Amb els límits al davant hi ha un ordre sensat: comandes, estoc i tracking primer, que són les tres crides que sostenen el magatzem; després listings, preus, FBA o devolucions si el negoci ho demana. Els informes van al final: no són difícils, consumeixen la quota lenta.

Què hauries de preguntar abans de comprar

• Quins fluxos estan suportats avui i per quina API entra cadascun.
• Si la connexió fa servir la teva aplicació o la del proveïdor, i qui rota el secret LWA.
• Què passa davant d'un 429: reintenta, encua, respecta Retry-After, deixa rastre?
• Com es tracten FBA, devolucions i adreces amb dades personals.
• Si en confirmar dues vegades el mateix enviament s'envia dues vegades el tracking.
• Si el proveïdor implanta o només ven llicència, i en quines versions manté el mòdul.

Si la integració no és amb Amazon sinó amb el teu propi programa de gestió, el plantejament és el mateix i ho expliquem a connector Odoo per al teu programari; el catàleg és a mòduls i el mapa per problema, a solucions.

Preguntes freqüents

Enllaços útils dins de FlexigoTech

El que fem sobre això