Connecter Amazon Seller Central à votre logiciel métier avec la Selling Partner API

De quoi a-t-on besoin avant d'écrire une ligne de code ?

L'accès à la Selling Partner API passe par un parcours administratif que la documentation d'Amazon décrit en détail. Pour un vendeur qui relie son propre logiciel, ce qu'Amazon appelle une application privée de vendeur, les étapes sont les suivantes :

1. Un compte vendeur Professionnel. La documentation SP-API précise que les comptes individuels ne sont pas éligibles aux applications privées.
2. L'enregistrement comme développeur dans le Solution Provider Portal, par l'utilisateur principal du compte, avec un profil développeur original de 500 mots au plus.
3. Les questions de sécurité du profil, qu'Amazon conseille de confier à l'équipe responsable de la sécurité des données.
4. La lecture des politiques : politique d'utilisation acceptable, politique de protection des données et accord du Solution Provider Portal, que la documentation demande de relire avant l'enregistrement.
5. Le choix des rôles, par exemple Inventory and Order Tracking ou Product Listing, qui ouvrent les opérations correspondantes.
6. L'auto-autorisation de l'application depuis Seller Central, à refaire quand on ajoute un rôle.

Une application publique, vendue à d'autres vendeurs, suit un autre circuit : autorisation OAuth par chaque vendeur depuis le site de l'éditeur ou l'Appstore d'Amazon, puis réautorisation annuelle. Ce cas concerne les éditeurs de logiciels, pas la PME qui branche son propre outil. Les conditions d'accès évoluent : relisez dans le Solution Provider Portal les conditions contractuelles et financières en vigueur au moment du projet.

Quelle API pour quel flux ?

Deux précisions de la documentation comptent pour un projet neuf : les flux XML et fichiers plats d'annonces produits de la Feeds API sont dépréciés, et l'Orders API ne renvoie pas les commandes de plus de deux ans. Pour la France, les appels partent vers le point d'accès Europe, sellingpartnerapi-eu.amazon.com.

Jetons, rôles et données des acheteurs : comment fonctionne l'authentification ?

Chaque appel à la SP-API transporte un jeton d'accès Login with Amazon (LWA) dans l'en-tête x-amz-access-token. Le service d'intégration obtient ce jeton en présentant au service d'authentification d'Amazon le jeton de rafraîchissement reçu à l'autorisation, avec l'identifiant et le secret de l'application. Selon la documentation SP-API, un jeton d'accès LWA expire une heure après son émission : son renouvellement doit être automatique.

Les données sensibles suivent une règle à part. Certaines opérations donnent accès à des données personnelles, utiles par exemple pour expédier ou facturer ; Amazon les classe comme opérations restreintes. Elles demandent un rôle restreint accordé à l'application, puis un jeton spécifique, le Restricted Data Token (RDT), obtenu par la Tokens API et présenté à la place du jeton LWA. La documentation demande de manipuler ces jetons avec un soin particulier.

Pour la PME, la conséquence est pratique : le cadrage doit lister dès le départ les opérations restreintes réellement nécessaires, par exemple pour imprimer les étiquettes des commandes expédiées par vos soins, et décider où ces données sont stockées et combien de temps, en cohérence avec la politique de protection des données d'Amazon et le RGPD.

Combien d'appels Amazon autorise-t-il ?

Amazon ne publie pas de quota unique : la SP-API applique un algorithme de seau à jetons. Chaque requête consomme un jeton, les jetons se reconstituent à un rythme fixé (la limite de débit) et le seau a une capacité maximale (la limite de rafale). Seau vide, la requête est refusée avec une erreur HTTP 429, que la documentation décrit comme réessayable, avec un délai d'attente croissant.

• Chaque opération a ses propres valeurs : lire une commande et publier une offre ne sont pas limitées de la même façon.
• La plupart des limites s'appliquent par couple vendeur et application.
• Certaines opérations relèvent de plans dynamiques ajustés selon l'activité du vendeur : appeler plus souvent ne fait pas monter la limite.
• L'en-tête x-amzn-RateLimit-Limit indique la limite quand il est présent, mais Amazon prévient qu'il peut manquer : le code ne doit pas en dépendre.

Amazon conseille lui-même de préférer les notifications à l'interrogation répétée et d'utiliser les opérations groupées quand elles existent. C'est la règle de conception qui évite d'enchaîner les 429 un jour de forte affluence.

Recevoir les événements par SQS ou EventBridge

La Notifications API envoie les événements Amazon au lieu d'obliger le logiciel métier à les réclamer. On crée une destination, file Amazon SQS ou bus Amazon EventBridge, puis un abonnement par type de notification, éventuellement filtré.

L'abonnement à ORDER_CHANGE exige le rôle Inventory and Order Tracking ou Amazon Fulfillment. La documentation d'Amazon recommande aussi de garder un moyen de récupérer les informations en cas de panne ou de retard : la file d'attente ne dispense pas d'une vérification périodique des commandes.

Quatre flux types pour un vendeur Amazon

1. La commande expédiée par le vendeur. ORDER_CHANGE arrive dans la file ; le service lit la commande et ses lignes, la crée dans le logiciel de gestion avec le SKU de chaque article, puis confirme l'expédition avec le transporteur et le numéro de suivi au départ du colis. L'identifiant de commande Amazon sert de clé : une notification reçue deux fois ne crée pas deux commandes.
2. Un stock pour plusieurs canaux. Un distributeur de pièces détachées vend sur son site et sur Amazon depuis le même entrepôt. À chaque mouvement, l'ERP recalcule le disponible et met à jour la quantité de l'offre par la Listings Items API, en gardant une marge de sécurité contre la survente. Notre page sur la gestion de stock multi-sites détaille ces règles.
3. Le stock confié à Amazon. L'ERP lit la FBA Inventory API pour connaître le stock disponible dans les entrepôts Amazon et proposer les réapprovisionnements depuis le dépôt principal.
4. Le rapprochement financier. La Finances API liste transactions et soldes ; le service les rattache aux commandes pour isoler commissions et frais, puis prépare les écritures comptables au lieu d'une ressaisie mensuelle.

Tester sans risquer son compte vendeur

La SP-API dispose d'un bac à sable hébergé, conçu pour tester sans affecter les données de production ni déclencher d'événements réels. Le bac à sable statique renvoie des réponses fixes quand la requête correspond aux exemples de la documentation ; le bac à sable dynamique renvoie des réponses réalistes, parfois avec un état, pour les opérations qui le prennent en charge. Pour l'Europe, dont la France, l'adresse est sandbox.sellingpartnerapi-eu.amazon.com.

Deux limites à connaître : ces environnements sont plafonnés à cinq requêtes par seconde avec une rafale de 15, et Amazon conseille de s'en servir pour vérifier les fonctions, pas la tenue en charge. Un test qui demande un RDT doit utiliser un jeton obtenu en production.

Logiciel multicanal ou intégration sur mesure : ce que livre YMHB Web

Un vendeur présent sur plusieurs places de marché avec un catalogue standard trouve souvent son compte dans un logiciel multicanal du marché, qui absorbe pour lui les évolutions de la SP-API, comme le passage de l'Orders API v0 à la nouvelle version. Le sur-mesure se justifie quand la logique est propre à l'entreprise : compatibilité de pièces, kits, règles de stock entre dépôts, rapprochement financier fin, ou ERP spécifique. Les places de marché opérées sur Mirakl relèvent d'une autre intégration, décrite sur notre page Mirakl.

Dans ce cas, YMHB Web développe un service d'intégration séparé : application enregistrée au nom du vendeur, secrets stockés hors du code, file SQS et journal des échanges sur le compte du client, écran de supervision des erreurs 429 et des commandes en attente, documentation des flux et de la procédure de reprise. Le code est remis au client au paiement intégral. La démarche générale est décrite sur notre page connecter ses logiciels par API.