Intégration de boutique avec Amazon : SP-API, offres et commandes

La connexion d’une boutique à Amazon s’organise autour du Selling Partner API et des accès du compte vendeur. Elle comprend produits, offres, quantités et commandes, mais les exigences varient selon le marché et la catégorie. Avant le développement, nous précisons qui exécute les commandes et quelles actions sont autorisées à l’application.

L’application doit être enregistrée et autorisée. Les permissions correspondent à des fonctions précises ; l’accès aux données personnelles impose des exigences supplémentaires. Nous prévoyons dès le départ la sécurité des identifiants et le renouvellement des jetons. Nous n’utilisons pas un compte opérateur partagé comme passerelle technique et ne supposons pas qu’une vente active donne automatiquement accès à toutes les fonctions API.

Nous vérifions si l’article existe déjà dans le catalogue Amazon et les caractéristiques exigées par sa catégorie. La connexion conserve le SKU de l’entreprise et les correspondances nécessaires avec le marché. Titres, conditionnements et variantes sont contrôlés séparément du prix et de la quantité disponible. Le traitement de l’envoi doit être suivi : une soumission techniquement réussie ne signifie pas automatiquement que l’offre est active.

Lorsque l’entreprise expédie elle-même, la connexion organise commandes et informations d’expédition avec le suivi réel. Avec FBA, l’exécution physique est différente et le stock commercial doit être distingué. Un champ de quantité commun à tous les cas peut donner une image fausse. Le flux est choisi avant de concevoir la synchronisation ERP.

Un fabricant grec souhaite proposer une gamme précise sur un marché européen Amazon. Il choisit d’abord un catalogue limité, vérifie les emballages et prépare un contenu linguistique adapté. La passerelle conserve un prix propre au canal, suit les rejets de fiches et importe les commandes avec leur identifiant externe. L’équipe commerciale convient des coûts, retours et expéditions avant d’activer la synchronisation. Cet exemple ne promet ni admission ni hausse des ventes.

Nous testons variations de stock, expiration des autorisations, limites temporaires de requêtes et soumissions échouées. La file de nouvelles tentatives doit préserver le dernier état correct sans envoyer d’anciens prix après une modification récente. Nous suivons aussi les versions de l’API. La documentation Orders actuelle inclut la nouvelle version v2026-01-01 : les anciennes consignes doivent être vérifiées avant tout nouveau projet.