La SP-API d'Amazon vue depuis Odoo : ce que vous autorisez, ce qui vous limite et ce qui ne casse qu'en production

SP-API est le sigle de Selling Partner API : l'interface par laquelle Amazon permet à un programme externe de lire et d'écrire dans votre compte Seller Central. Elle a remplacé MWS et a changé bien plus que le nom. Côté Odoo, l'API elle-même est la partie facile : ce sont des requêtes HTTP avec du JSON. Ce qui décide si l'intégration tiendra un mois de novembre, ce sont trois choses qu'on ne voit pas dans la documentation d'un endpoint : comment elle est autorisée, combien d'appels vous sont permis et quelles données arrivent en retard par conception.

L'autorisation se signe dans Seller Central, pas dans Odoo

Le flux est toujours le même : une application est enregistrée avec un profil de développeur et vous, en tant que vendeur, l'autorisez depuis votre compte. De cette autorisation découle un refresh token de longue durée, qu'Odoo conserve ; avec lui, Odoo demande, chaque fois qu'il en a besoin, un jeton d'accès qui dure une heure. Si l'on vous demande vos identifiants Seller Central pour « le configurer », quelque chose ne va pas : personne n'a besoin de votre mot de passe pour cela. Et si vous révoquez l'autorisation, l'intégration s'arrête net, ce qui est exactement ce qui doit se passer.

Les données de l'acheteur passent par une porte à part

Le nom, l'adresse et le téléphone de l'acheteur sont des données personnelles et Amazon les traite comme telles : elles ne figurent pas dans la réponse normale d'une commande. Il faut demander un jeton restreint pour cette requête précise, et l'autorisation de le faire est accordée par rôle, pas par défaut. Conséquence pratique dans Odoo : vous pouvez avoir des commandes qui s'importent parfaitement et des bons de livraison impossibles à expédier faute d'adresse. Ce n'est pas un défaut du connecteur ; c'est l'autorisation qui n'a pas été approuvée.

Les limites d'appels sont un budget, pas une vitesse

Chaque opération de la SP-API a sa propre limite et fonctionne comme un réservoir qui se remplit à un rythme fixe et admet une courte rafale au-dessus. Tant qu'il reste du crédit, vous allez vite ; quand il est épuisé, Amazon répond 429 et il faut attendre. Cela se traduit directement pour Odoo : vous ne pouvez pas parcourir 4 000 références en appelant une par une « parce que c'est plus simple ». Il faut regrouper, respecter l'en-tête de limite que renvoie l'API elle-même et réessayer avec une attente croissante. Et il faut que la synchronisation manuelle et le cron partagent le même frein, car le budget est celui du compte entier, pas de chaque processus.

Rapports et appels en direct : pourquoi votre stock a toujours du retard

La SP-API a deux façons de vous donner des données. L'une est l'appel direct : vous demandez les commandes depuis une date et elle répond sur-le-champ. L'autre est le système de rapports, qui est asynchrone : vous demandez le rapport, Amazon le prépare quand il peut, vous vérifiez s'il est prêt, puis vous téléchargez un fichier compressé. L'inventaire FBA et les règlements passent par là. Cela signifie que le stock que vous voyez dans Odoo est celui du dernier téléchargement, pas celui de cette seconde, et aucune fréquence de cron n'y change rien. La bonne réponse n'est pas d'appeler plus souvent : c'est de publier avec une marge de sécurité et d'assumer le décalage.

Les erreurs qui n'apparaissent qu'en production

Ce sont toujours les mêmes et aucune n'apparaît le premier jour. Des commandes en statut « en attente » qui arrivent sans montants ni adresse et qu'il faut relire plus tard. La pagination : la première page entre et le reste se perd si personne ne suit le jeton de continuation. Des fenêtres de dates mal calculées à cause du fuseau horaire, qui laissent un trou de commandes juste au changement de jour. Des jetons qui expirent pendant une longue synchronisation et qu'il faut renouveler en cours de route. Et la mauvaise région : l'application est globale, mais le compte vendeur ne l'est pas, et demander les commandes d'Allemagne à l'endpoint d'Amérique du Nord ne répond pas « région incorrecte », il répond « Access to requested resource is denied ». On dirait un problème de permissions, alors on régénère des identifiants qui étaient bons, pendant que l'erreur reste dans l'URL.

Où cela doit vivre dans Odoo

Un appel à Amazon ne peut pas dépendre de la validation d'un bon de livraison. Si l'API est lente, l'utilisateur reste devant une roue qui tourne et, si elle échoue, il perd le travail effectué. La place de ces appels est une action planifiée ou une file de tâches, avec ses réessais, son journal de ce qui a été demandé et de ce qu'Amazon a répondu, et des opérations idempotentes : rejouer une synchronisation ne doit pas créer la commande deux fois. Ce journal est ce qui vous permet ensuite de discuter avec le support d'Amazon avec des données plutôt qu'avec des impressions. Le reste du schéma, appliqué aux commandes qui n'apparaissent pas, se trouve dans pourquoi les commandes Amazon n'entrent pas dans Odoo.

Quand vous n'avez rien à construire

Si vous vendez sur une seule marketplace, avec peu de références, et que vous avez seulement besoin que les commandes arrivent, le connecteur Amazon fourni de série avec Odoo Enterprise peut vous suffire. Il vaut la peine de l'essayer avant de payer quoi que ce soit. La discussion change quand il y a plusieurs pays avec leurs taxes, un stock partagé avec d'autres canaux, des règlements à rapprocher ou des confirmations d'expédition avec un délai. C'est là que notre connecteur Amazon pour Odoo fait le travail : SP-API avec contrôle des limites, rapports, FBA et FBM, sur Odoo 17, 18, 19 et 20.

Questions fréquentes

Liens utiles chez FlexigoTech

Ce que nous faisons à ce sujet