Ce qu'est la Selling Partner API et ce qu'elle a remplacé
Tout outil sérieux qui touche à votre compte Amazon, du repricer à l'export comptable en passant par une application d'alerte de commande, parle au même endroit : la Selling Partner API, abrégée en SP-API. Une application ne voit jamais que ce que vous avez autorisé.
Elle est aussi récente. Sa devancière s'appelait Amazon Marketplace Web Service, MWS en abrégé. Amazon en a annoncé la fin sur son forum vendeurs : « SP-API will fully replace MWS, and we are migrating developers to SP-API as we work to deprecate MWS », autrement dit la SP-API remplace entièrement MWS. Avec une date ferme : MWS « will no longer be available after March 31, 2024 ». Si un vieux tutoriel vous explique comment générer des clés MWS, il décrit un système qui n'existe plus.
L'API Amazon Seller Central n'existe pas au singulier
On cherche « API Amazon Seller Central » comme s'il s'agissait d'une seule interface. C'est une famille : une Orders API pour les commandes, une Sales API pour les totaux du jour, une Reports API pour les rapports que vous téléchargez aussi à la main, une Notifications API pour les messages push, une Finances API pour les transactions. Une application d'alerte en utilise trois au maximum.
La SP-API est également découpée par région. L'Europe, l'Amérique du Nord et l'Extrême-Orient sont des points d'entrée distincts avec des autorisations distinctes. C'est pour cela qu'une application vous demande de connecter votre compte une fois pour l'Europe, puis une seconde fois pour l'Amérique du Nord si vous vendez des deux côtés. C'est la raison technique derrière la structure de comptes décrite dans vendre sur plusieurs places de marché Amazon.
Ce que vous accordez quand une application se connecte
L'accès n'est pas un mot de passe. Vous arrivez sur une page de consentement hébergée par Amazon, vous voyez les rôles demandés, et vous appuyez sur Confirm. Vos identifiants ne passent jamais par l'application.
Les rôles méritent d'être lus. Amazon décrit celui dont une application de commandes a besoin ainsi : « The Inventory and Order Tracking role provides access to operations that analyze and manage inventory. » Il couvre la lecture des commandes et l'abonnement à ORDER_CHANGE. Les rôles qui exposent les noms et adresses des acheteurs forment une catégorie restreinte à part, soumise à un examen plus lourd, et une application d'alerte n'a aucune raison de les demander.
Deux points que les vendeurs entendent rarement. L'autorisation n'est pas éternelle : Amazon écrit que « the selling partner must reauthorize your public application every 365 days, or anytime you add a role to your application », soit un renouvellement annuel. Et vous pouvez y mettre fin en une minute dans Seller Central, sous Apps and Services, Manage Your Apps. La marche à suivre complète est dans comment connecter une application à Seller Central en sécurité.
ORDER_CHANGE : le message et la file d'attente derrière
La Notifications API d'Amazon propose une vingtaine de types de notifications. Celui qui compte pour les commandes est ORDER_CHANGE : « The ORDER_CHANGE notification is sent whenever there is an important change in the order. Important changes include order status changes and buyer requested cancelations. » En français : le message part à chaque changement important, ce qui inclut les changements de statut et les demandes d'annulation de l'acheteur. Un type plus ancien, ORDER_STATUS_CHANGE, existe encore, mais le tutoriel d'Amazon le déclare « deprecated » et renvoie vers ORDER_CHANGE.
C'est sur la livraison que la plupart des gens se trompent. Pour ce type, Amazon n'envoie rien vers une adresse webhook de votre choix. Amazon écrit dans une file Amazon SQS, une file de messages que l'éditeur crée dans son propre compte cloud et sur laquelle il autorise Amazon à écrire. La page de configuration d'Amazon liste ORDER_CHANGE parmi les types livrés ainsi, et ajoute une contrainte révélatrice : « Selling Partner API does not support delivery to FIFO queues. You must use Amazon SQS standard queues to receive notifications. »
Une file standard peut livrer un message plusieurs fois et dans le désordre. C'est normal, et c'est pourquoi une application soigneuse garde la trace de chaque identifiant de notification déjà traité. Quand une application joue deux fois le même cha-ching, l'erreur vient presque toujours de là.
Ce que le message contient et ce qu'il laisse de côté
Le message est compact et construit autour de la commande, pas autour de l'article. Amazon le dit clairement : « If you have multiple order items in the order, you will receive consolidated payloads at the order level. » Une commande avec quatre produits donne donc un message contenant quatre lignes, et non quatre alertes.
| Dans le message | Ce que cela vous dit |
|---|---|
| AmazonOrderId | Le numéro de commande, celui que vous voyez dans Seller Central |
| OrderStatus | Pending, Unshipped, PartiallyShipped, Shipped, Canceled et quelques autres |
| MarketplaceId | La place de marché où la vente a eu lieu, par exemple amazon.fr |
| PurchaseDate | Le moment de la commande, qui n'est pas celui de la publication du message |
| FulfillmentType | MFN ou AFN, autrement dit expédié par le vendeur ou Expédié par Amazon |
| OrderItems | Pour chaque article, le SKU vendeur et la quantité |
Il manque précisément ce qui intéresse le plus les vendeurs : ni montant de la commande, ni prix unitaire, ni ASIN, ni titre du produit. Les solutions architects d'Amazon présentent ORDER_CHANGE comme un déclencheur pour aller chercher la commande complète dans l'Orders API, pas comme un remplacement. Une application qui vous affiche un montant a donc fait un second appel.
Ce second appel a une limite dans les premières minutes. Amazon définit Pending comme « The order has been placed but payment has not been authorized », donc paiement non encore autorisé. Pendant ce temps, « the getOrderItems operation does not return information about pricing, taxes, shipping charges, gift status or promotions ». Le statut Pending dure en général une demi-heure, puisque « the fulfillable date of an order is usually 30 minutes after the order has been created ». Tout montant affiché dans les premières minutes est donc une estimation. Nous affichons le nôtre avec un signe « ≈ » et le corrigeons en silence dès qu'Amazon publie le vrai chiffre, pour les raisons détaillées dans ce que signifie une commande en attente pour un vendeur.
Un champ mérite une note : le message contient le code postal de destination, et la Data Protection Policy d'Amazon range un code postal parmi les données personnelles. Une application qui ne veut aucune donnée acheteur sur ses serveurs jette ce champ avant tout enregistrement. C'est ce que fait la nôtre.
Pourquoi les commandes FBA restent muettes en Pending
Voici la partie absente de la documentation, parce que nous ne l'avons découverte qu'en mesurant sur notre propre compte vendeur.
Ce que nous avons mesuré
Le 28 août 2026, nous avons fait tourner notre chaîne de commandes sur notre propre compte vendeur Amazon (Expédié par Amazon sur les places de marché européennes, surtout amazon.de).
- 14 commandes en une journée, 0 manquée.
- Médiane de 200 secondes entre la commande et le son sur le téléphone, en interrogeant l'Orders API chaque minute.
- Deux commandes du soir sont arrivées en 155 et 136 secondes.
- Amazon n'a envoyé aucune notification ORDER_CHANGE pour une commande FBA tant qu'elle était en Pending. La première push est arrivée à un statut ultérieur, et des commandes sont restées des heures en Pending.
- De nouvelles commandes en Pending n'apparaissaient parfois dans l'Orders API que 10 à 15 minutes après l'achat. Notre poller regarde donc 30 minutes en arrière à chaque passage.
Si la notification push est votre seul canal, un vendeur FBA apprend la vente au moment où le paiement est autorisé, ce qui sur notre compte s'est produit des heures après le clic de l'acheteur, pas en quelques secondes. C'est pourquoi nous travaillons en trois couches, dans l'ordre inverse de celui que suggèrent la plupart des schémas d'architecture.
| Couche | Ce qu'elle fait | Délai habituel | Faiblesse |
|---|---|---|---|
| 1. Interrogation de l'Orders API | Demande à Amazon chaque minute les commandes des 30 dernières minutes | Médiane de 200 secondes de la commande au téléphone dans notre mesure | Jusqu'à une minute d'attente par construction, et les nouvelles commandes en Pending apparaissent parfois après 10 à 15 minutes |
| 2. Push ORDER_CHANGE via SQS | Amazon publie un message à chaque changement important | Amazon parle de « usually trivial (in seconds) », jusqu'à 2 minutes le Prime Day | Muette pour les commandes FBA en Pending sur notre compte, et sans niveau de service |
| 3. Réconciliation nocturne | Compare la journée au rapport de commandes d'Amazon | Tourne la nuit, car les rapports demandent plus de temps | Bien trop lente pour alerter, mais elle rattrape ce que les deux premières couches ont laissé passer |
La troisième couche n'est pas notre idée. Amazon la recommande : « As a best practice, we recommend that you have a means to retrieve needed information in the event of an unexpected outage or delay in notification delivery. » Une application sans filet perdra un jour une commande sans jamais vous le dire. Le détail du temps réellement écoulé est dans à quelle vitesse une alerte de commande Amazon peut vraiment arriver.
Ce que cela change au moment de choisir une application
Vous n'avez pas besoin de lire une ligne de code pour juger une application d'alerte. Quatre questions séparent les sérieuses des autres.
- Quelles couches utilise-t-elle ? La notification push seule est la moins chère à construire et c'est justement celle qui se tait pour les commandes FBA en Pending. Demandez si l'application interroge aussi l'API, et à quelle fréquence.
- Compte-t-elle ce qu'elle a manqué ? Un filet ne sert que si le résultat est visible. Notre application affiche un compteur de commandes manquées avec un objectif de zéro, et chaque alerte indique son temps de trajet.
- Quels rôles demande-t-elle ? Vous les voyez sur la page de consentement avant de confirmer. Un seul rôle en lecture suffit. Une demande d'adresses acheteurs sur une application d'alerte est un motif d'arrêt.
- Que conserve-t-elle ? Le message contient un code postal, qu'Amazon traite comme une donnée acheteur. Demandez s'il est jeté, et à quelle vitesse tout disparaît quand vous coupez la connexion.
Si vous hésitez encore à passer par une application tierce, commencez par ce que l'application Amazon Seller envoie et n'envoie pas.
Questions fréquentes
Qu'est-ce que la SP-API d'Amazon ?
SP-API est l'abréviation de Selling Partner API. C'est l'ensemble des interfaces publiées par Amazon pour que des applications lisent et gèrent un compte vendeur avec l'accord du vendeur : commandes, totaux de ventes, rapports, notifications et finances. Elle a remplacé Amazon Marketplace Web Service, qui selon Amazon n'était plus disponible après le 31 mars 2024. En tant que vendeur, vous ne l'utilisez jamais directement ; les applications que vous autorisez s'en servent pour vous.
Comment configurer une alerte de commande Amazon ?
Trois réglages existent. Dans Seller Central, sous Paramètres puis Préférences de notification, vous choisissez les e-mails qu'Amazon envoie. Dans l'application Amazon Seller, vous réglez les notifications push, qui ne couvrent que les commandes expédiées par le vendeur. Pour une alerte sur chaque commande, y compris FBA, il faut une application connectée via la SP-API qui s'abonne à ORDER_CHANGE et interroge l'Orders API en secours.
Comment ne plus recevoir les notifications d'Amazon ?
Les e-mails vendeur se coupent dans Seller Central, sous Paramètres puis Préférences de notification, où se trouve aussi le récapitulatif toutes les deux heures des commandes FBA expédiées. Certaines alertes liées au compte et aux performances ne se désactivent pas. Et pour une application tierce, la coupure est ailleurs : dans Seller Central, sous Apps and Services, Manage Your Apps, vous retirez l'autorisation en une minute.
Comment obtenir un accès à la SP-API ?
Vous vous enregistrez d'abord comme développeur auprès d'Amazon, puis vous enregistrez l'application. Amazon distingue les applications privées, auto-autorisées pour votre seul compte, des applications publiques, celles qui « are publicly available and are authorized by sellers or by vendors using OAuth » et passent par un examen plus long. La plupart des vendeurs n'ont pas à le faire, puisque l'application qu'ils installent s'en est déjà chargée.
Sources
- https://developer-docs.amazon.com/sp-api/docs/notification-type-values
- https://developer-docs.amazon.com/sp-api/docs/tutorial-subscribe-to-order-change-notification
- https://developer-docs.amazon.com/sp-api/docs/set-up-notifications-with-amazon-sqs
- https://developer-docs.amazon.com/sp-api/docs/notifications-api
- https://developer-docs.amazon.com/sp-api/docs/orders-api-v0-reference
- https://developer-docs.amazon.com/sp-api/docs/report-type-values-order
- https://developer-docs.amazon.com/sp-api/docs/role-mappings-for-types
- https://developer-docs.amazon.com/sp-api/docs/roles-in-the-selling-partner-api
- https://developer-docs.amazon.com/sp-api/docs/renew-authorizations
- https://developer-docs.amazon.com/sp-api/docs/sp-api-registration-overview
- https://developer-docs.amazon.com/sp-api/docs/data-protection-policy
- https://github.com/amzn/selling-partner-api-samples/discussions/104
- https://sellercentral.amazon.com/seller-forums/discussions/t/6403cff0d2c92b4ef066d93210fe51a3
