Connecteur Amazon pour Odoo : quels identifiants SP-API demande, quelles limites de débit s'appliquent et ce qu'il doit couvrir

Si vous cherchez un connecteur Amazon Odoo ou Amazon SP-API Odoo, la réponse courte est la suivante : il faut trois identifiants qui ne viennent pas du même endroit (une application SP-API enregistrée par un profil développeur avec les rôles approuvés, les clés LWA de cette application et un refresh token par vendeur qui l'autorise), plus le marketplace id et le endpoint régional. Et une décision de conception : les limites sont des seaux de jetons par opération, donc le connecteur utilise une file et un backoff, pas des boucles.

Tout ce qui suit a été vérifié le 13 septembre 2026 dans la documentation de SP-API et dans le code de notre Connecteur Amazon Seller pour Odoo, publié sur les branches 19.0, 18.0 et 17.0, avec 786 tests propres sur celle d'Odoo 19 et 685 sur chacune des deux autres.

Ce que doit résoudre un connecteur Amazon Odoo

• Import fiable des commandes et réservation du stock.
• Mapping des SKU, variantes et listings sans doublons.
• Synchronisation des statuts, du suivi et des confirmations.
• Gestion des prix, des incidents et des cas d'erreur.
• Prise en charge de FBA quand elle fait partie de l'activité.
• Logs et nouvelles tentatives quand Amazon ou la file interne échoue.

Chaque ligne passe par une porte différente (/orders/v0, /listings/2021-08-01, /feeds/2021-06-30, /reports/2021-06-30) et chaque porte a sa propre limite.

Quels identifiants SP-API demande et qui les fournit

1. L'application. SP-API ne s'ouvre pas avec l'utilisateur de Seller Central, mais avec une application enregistrée dans le Solution Provider Portal par un profil développeur approuvé. À l'enregistrement, on choisit des rôles (Amazon en documente dix-huit) et on ne peut choisir que ceux déjà approuvés. Quatre sont restreints car ils touchent à des données personnelles, dont Direct-to-Consumer Shipping. Et avoir le rôle ne suffit pas : l'adresse de livraison se demande avec un restricted data token (POST /tokens/2021-03-01/restrictedDataToken).

2. Les clés LWA. L'application fournit un client_id et un client_secret de Login with Amazon. Le secret expire au bout de 180 jours : Amazon prévient 90 jours avant et l'ancien tient sept jours de plus. Passé ce délai, les appels échouent sans que personne n'ait rien touché, et le symptôme (invalid_client en pleine nuit) ne ressemble pas à sa cause ; c'est pourquoi le connecteur conserve cette date et prévient avec un cron quotidien.

3. Le refresh token du vendeur. C'est la seule chose que vous ne renseignez pas : c'est le vendeur qui la génère en autorisant l'app sur sellercentral…/apps/authorize/consent, avec le application_id et un state propre ; si l'app est encore en brouillon, on ajoute &version=beta, et à la publication il faut l'enlever. Amazon le renvoie à votre redirect URI avec un spapi_oauth_code à échanger en moins de cinq minutes sur https://api.amazon.com/auth/o2/token : on obtient un access_token, qui expire au bout d'une heure, et le refresh_token.

4. Marketplace et région. Un compte n'est pas un pays : c'est un marketplace id (Espagne A1RKKUPIHCS9HS, France A13V1IB3VIYZZH) qui pointe vers un endpoint régional, https://sellingpartnerapi-eu.amazon.com en Europe. Notre connecteur fournit les 23 marketplaces sous forme de données et chaque compte pointe vers un seul, pour que le stock, les taxes et le canal viennent du bon endroit.

Limites de débit : pourquoi le connecteur a besoin d'une file

Amazon répartit le trafic avec un seau de jetons : chaque opération a un débit (jetons par seconde) et un burst (capacité), et chaque requête consomme un jeton. Quand le seau se vide, un 429 arrive, que la documentation qualifie de réessayable, et (quand il est disponible, ce qui n'est pas toujours le cas) l'en-tête x-amzn-RateLimit-Limit revient avec la limite de votre couple vendeur-application. Les limites sont par opération, et celles du tableau sont les valeurs par défaut, qu'Amazon peut relever pour qui traite plus de volume.

Ce tableau explique la conception. Comme getOrders est limité à une par minute, les commandes se lisent avec un filigrane (LastUpdatedAfter) et une pagination par NextToken depuis un cron toutes les quinze minutes, pas avec un bouton. Comme il faut attendre les rapports, le cycle est créer, interroger et télécharger : nous interrogeons jusqu'à douze fois toutes les dix secondes. Et comme les appels de rapports partagent un seau, face à un 429 le connecteur écrit un délai de refroidissement partagé de 90 secondes et l'inventaire FBA bascule sur l'API en direct.

La nouvelle tentative vit dans une seule fonction : 429 et 500, 502, 503 et 504 sont réessayés, Retry-After est respecté et, s'il n'est pas fourni, on attend un backoff exponentiel à partir de 1,5 seconde avec un bruit aléatoire pour que deux crons ne reviennent pas en même temps. Si la dernière tentative échoue aussi, l'erreur contient le Retry-After, l'en-tête de quota et le chemin : le log dit quel quota s'est épuisé, pas « erreur de synchronisation ».

D'où la règle : ce qui écrit va dans une file avec clé d'idempotence ; ce qui lit passe avec un filigrane. La confirmation d'expédition peut rester en file à l'état « en attente » et, dans ce cas, le seul à envoyer est un cron toutes les cinq minutes qui prend au maximum 200 bons de livraison des trois derniers jours, avec un verrou par bon de livraison qui empêche d'envoyer deux fois le même suivi. Prix et stock ont leur propre file chaque minute ; si une écriture échoue, une autre file la réessaie toutes les 180 secondes, vingt fois au maximum par SKU.

Pourquoi Amazon casse des opérations quand Odoo ne commande pas

Si le stock vient de plusieurs endroits ou si le suivi est géré hors de l'ERP, les incidents arrivent : commandes non mappées, inventaire incohérent et service après-vente plus coûteux. Avec les limites en main, on voit pourquoi le canal qui publie le stock doit être unique : le publier deux fois coûte le double de quota. Nous le développons dans stock en temps réel sur les marketplaces et dans vendre sur plusieurs marketplaces depuis un seul Odoo.

Erreurs fréquentes d'Amazon SP-API dans Odoo

Presque tous les échecs que nous voyons viennent de ces trois identifiants, pas du code : un redirect URI qui pointe vers un autre Odoo, si bien que le retour du vendeur atterrit sur un écran disant que personne ne l'attendait ; une autorisation avec version=beta alors que l'app est déjà publiée ; le secret LWA expiré ; le rôle restreint non approuvé, qui ne donne pas d'erreur claire mais des adresses vides ; et la boucle de 429 quand quelqu'un réessaie à la main pendant que le cron réessaie aussi.

Chacun a un symptôme qui ne ressemble pas à sa cause, nous les avons donc réunis avec leur diagnostic dans Amazon SP-API et Odoo : erreurs fréquentes et comment les éviter. Si votre sujet est la mise en place, le parcours se trouve dans comment intégrer Amazon avec Odoo 19.

Commencez par ce qui fait le plus mal

Avec les limites en main, il y a un ordre sensé : commandes, stock et suivi d'abord, les trois appels qui font tenir l'entrepôt ; ensuite listings, prix, FBA ou retours si l'activité le demande. Les rapports viennent en dernier : ils ne sont pas difficiles, ils consomment le quota lent.

Ce que vous devriez demander avant d'acheter

• Quels flux sont pris en charge aujourd'hui et par quelle API passe chacun.
• Si la connexion utilise votre application ou celle du fournisseur, et qui fait tourner le secret LWA.
• Ce qui se passe face à un 429 : réessaie-t-il, met-il en file, respecte-t-il Retry-After, laisse-t-il une trace ?
• Comment sont traités FBA, les retours et les adresses contenant des données personnelles.
• Si, en confirmant deux fois la même expédition, le suivi est envoyé deux fois.
• Si le fournisseur déploie ou ne fait que vendre une licence, et sur quelles versions il maintient le module.

Si l'intégration n'est pas avec Amazon mais avec votre propre logiciel de gestion, l'approche est la même et nous l'expliquons dans connecteur Odoo pour votre logiciel ; le catalogue est dans modules et la carte par problème, dans solutions.

Questions fréquentes

Liens utiles chez FlexigoTech

Ce que nous faisons à ce sujet