Synchroniser les stocks sur Amazon, eBay et Walmart via les API

Un registre central, trois modes d’écriture

En bref : conservez une seule valeur de stock dans un système que vous contrôlez, puis transmettez-la à chaque marketplace via sa propre API d’écriture. Amazon, eBay et Walmart ne communiquent pas entre eux, et aucune de ces plateformes ne vous avertira lorsqu’un autre canal vend votre dernière unité. La synchronisation relève donc de votre responsabilité.

C’est plus complexe qu’il n’y paraît, car les trois API diffèrent sur presque tout : la manière d’indiquer une quantité, le nombre d’articles acceptés par appel et la signification réelle d’une réponse positive. Ce guide présente d’abord le mode d’écriture propre à chaque canal, puis les règles de conception qui permettent de garder des stocks fiables. Les informations ci-dessous ont été vérifiées dans la documentation développeur des plateformes le 29 septembre 2026.

Une architecture robuste repose sur un registre central et un adaptateur léger par canal :

• Registre : stock disponible moins les unités réservées par les commandes ouvertes de tous les canaux.
• Couche de règles : seuils de sécurité et plafonds propres à chaque canal, qui transforment la valeur du registre en quantité vendable.
• Adaptateurs : conversion de la quantité vendable en appels Amazon, eBay ou Walmart, avec enregistrement de ce que chaque canal a accepté.
• Outil de rapprochement : lecture des quantités réelles sur chaque canal et signalement des écarts.

Mettre à jour les stocks sur Amazon avec la SP-API

Amazon propose deux modes d’écriture. L’API Listings Items met à jour une annonce à la fois. Pour les opérations en masse, le guide Amazon de l’API Listings Items vous oriente vers le type de flux JSON_LISTINGS_FEED dans l’API Feeds, qui utilise les mêmes schémas. Les deux méthodes nécessitent le rôle Inventory and Order Tracking ou Product Listing pour votre application.

La quantité d’une offre expédiée par le vendeur se trouve dans l’attribut fulfillment_availability, avec le code de canal DEFAULT. Voici à quoi ressemble une requête (ATVPDKIKX0DER est l’identifiant de la marketplace américaine ; utilisez le véritable type de produit de l’annonce, car PRODUCT sert de solution de repli pour les types que l’API ne prend pas entièrement en charge) :

PATCH /listings/2021-08-01/items/{sellerId}/{sku}?marketplaceIds=ATVPDKIKX0DER
{
  "productType": "PRODUCT",
  "patches": [
    {
      "op": "replace",
      "path": "/attributes/fulfillment_availability",
      "value": [
        { "fulfillment_channel_code": "DEFAULT", "quantity": 12 }
      ]
    }
  ]
}

Quatre comportements d’Amazon qui mettent en échec les synchronisations naïves

• Utilisez patch, jamais put. Une opération put remplace le contenu de l’annonce, et les attributs omis peuvent être supprimés. Pour modifier une quantité, utilisez patch. Amazon prend également en charge une opération merge qui ne met à jour que quantity dans fulfillment_availability ; vous n’avez donc pas à renvoyer des champs comme la date de réapprovisionnement ou le délai d’expédition.
• Deux vues pour une même valeur. La section des attributs affiche la dernière valeur envoyée ; la section fulfillmentAvailability affiche la disponibilité réelle. Dans l’exemple fourni par Amazon, vous envoyez 1, l’unité est vendue, puis les attributs indiquent toujours 1 alors que la disponibilité réelle indique 0. Effectuez le rapprochement avec la section réelle, pas avec la dernière valeur envoyée.
• Accepté ne signifie pas actif. La réponse d’un patch indique uniquement que la demande a été acceptée pour traitement. Les problèmes détectés ensuite apparaissent lorsque vous appelez getListingsItem.
• Le stock FBA ne se définit pas via cette méthode. La quantité concerne le stock expédié par le vendeur. Lorsqu’une annonce possède à la fois du stock FBA et du stock expédié par le vendeur, les recommandations d’Amazon sur les modes d’expédition multiple indiquent que les unités FBA sont utilisées en premier, puis les unités expédiées par le vendeur une fois le stock FBA épuisé.

Mettre à jour les stocks sur eBay avec l’Inventory API

eBay sépare le modèle en deux éléments. Un item d’inventaire est l’enregistrement au niveau du SKU, avec la quantité totale expédiable à domicile. Une offre est l’annonce propre à une marketplace construite à partir de ce SKU. L’appel bulkUpdatePriceQuantity peut modifier, en une seule requête, la quantité totale de 25 items d’inventaire au maximum, ainsi que le prix ou la quantité d’offres publiées spécifiques. Il nécessite le périmètre OAuth sell.inventory.

POST https://api.ebay.com/sell/inventory/v1/bulk_update_price_quantity
{
  "requests": [
    {
      "sku": "WIDGET-BLK-01",
      "shipToLocationAvailability": { "quantity": 11 },
      "offers": [
        { "offerId": "9876543210", "availableQuantity": 11 }
      ]
    }
  ]
}

Quatre comportements d’eBay à prendre en compte

• La plus petite valeur l’emporte. Le champ availableQuantity d’une offre correspond à la quantité disponible sur cette marketplace et ne doit pas dépasser le total du SKU. L’annonce active affiche la plus petite des deux valeurs. Une valeur d’offre obsolète peut donc limiter silencieusement la quantité visible par les acheteurs. Envoyez les deux valeurs ensemble.
• Lisez la réponse ligne par ligne. La réponse renvoie un statut, un identifiant d’offre et un SKU pour chaque ligne, avec les erreurs et avertissements associés à chaque ligne. Vérifiez chaque ligne au lieu de considérer l’appel comme entièrement réussi.
• 25 articles par appel, cela finit par compter. Un catalogue de 10 000 SKU nécessite 400 appels pour un balayage complet, avant même les nouvelles tentatives. Planifiez la fréquence de ce balayage en conséquence.
• Les annonces historiques doivent être migrées. Les annonces créées avec l’Inventory API ne peuvent pas être modifiées avec l’ancienne Trading API. Si vos annonces eBay proviennent d’importations CSV ou d’outils utilisant la Trading API, utilisez l’appel bulkMigrateListing pour convertir les annonces actives éligibles vers le modèle Inventory API avant toute automatisation.

Mettre à jour les stocks sur Walmart Marketplace

La présentation de l’API Marketplace Inventory de Walmart associe chaque scénario à un endpoint. Le SKU doit déjà être configuré dans Walmart avant que vous puissiez gérer son stock. L’API couvre les vendeurs aux États-Unis, au Canada, au Mexique et au Chili.

Un nœud d’expédition est un centre de traitement, par exemple l’un de vos entrepôts. Voici à quoi ressemble un flux JSON pour un seul nœud :

POST https://marketplace.walmartapis.com/v3/feeds?feedType=inventory
{
  "InventoryHeader": { "version": "1.4" },
  "Inventory": [
    {
      "sku": "SKU_012345",
      "quantity": { "unit": "EACH", "amount": 10 },
      "inventoryAvailableDate": "2026-10-01"
    }
  ]
}

Trois comportements de Walmart à prendre en compte

• Les traitements en masse sont asynchrones. L’envoi d’un flux renvoie un identifiant de flux, et non un résultat. Interrogez l’API Feed Status pour obtenir le statut de chaque ligne et ne considérez une ligne comme terminée que lorsqu’elle indique done.
• Les endpoints en masse sont soumis à une limitation de débit. Le guide des stocks en masse de Walmart signale que les endpoints POST de flux sont soumis à un throttling. Mettez donc les envois en file d’attente et augmentez progressivement le délai entre les tentatives au lieu de relancer en boucle serrée.
• Les flux multi-nœuds nécessitent des nœuds d’expédition. Si vous n’incluez pas les nœuds d’expédition dans un flux multi-nœuds, celui-ci échoue.

Walmart propose également un événement de rupture de stock via son API Notifications. Il peut servir de déclencheur pour effectuer immédiatement une nouvelle vérification plutôt que d’attendre le prochain balayage.

Amazon, eBay ou Walmart : comparaison des mises à jour de stock

Éviter la survente sur plusieurs canaux

Aucune architecture d’API ne peut supprimer complètement le risque : deux canaux peuvent vendre la même unité à la même seconde. En revanche, vous pouvez limiter les conséquences et détecter rapidement l’incident. Les règles suivantes y contribuent.

1. Décrémentez le registre à partir des commandes, pas de vos envois. Comme la valeur réelle affichée par Amazon peut différer de la dernière valeur envoyée, les commandes constituent le signal fiable indiquant qu’une unité a été vendue.
2. Envoyez des quantités absolues, jamais des écarts. Si un envoi est relancé ou reçu deux fois, une valeur absolue reste sans danger. Un écart serait comptabilisé deux fois.
3. Conservez un stock tampon pour chaque canal. Retenez quelques unités sur le canal qui vend le plus rapidement afin qu’une éventuelle course porte sur du stock gardé en réserve.
4. Réservez dès la création de la commande, puis recalculez les trois canaux. Une commande eBay doit réduire la quantité vendable sur Amazon et Walmart au cours du même cycle.
5. Effectuez un rapprochement par lecture de retour. Récupérez les quantités réelles (fulfillmentAvailability pour Amazon, getInventoryItem pour eBay, GET /v3/inventory pour Walmart) et déclenchez une alerte lorsque l’écart dépasse votre seuil tampon.

La couche de règles peut rester très simple. Les valeurs de seuil et de plafond sont données à titre d’exemple ; adaptez-les à votre vitesse d’écoulement.

from dataclasses import dataclass

@dataclass
class ChannelRule:
    buffer: int   # units held back from this channel
    cap: int      # max units listed here, 0 means no cap

RULES = {
    'amazon':  ChannelRule(buffer=2, cap=0),
    'ebay':    ChannelRule(buffer=3, cap=50),
    'walmart': ChannelRule(buffer=2, cap=0),
}

def sellable(channel, on_hand, reserved):
    rule = RULES[channel]
    qty = max(on_hand - reserved - rule.buffer, 0)
    return min(qty, rule.cap) if rule.cap else qty

Avec 20 unités en stock et 6 unités réservées, cette fonction renvoie 12 pour Amazon, 11 pour eBay et 12 pour Walmart. Chaque adaptateur transmet ensuite sa propre valeur.

Temps réel ou traitement par lots : quelle fréquence de synchronisation choisir ?

Utilisez les deux approches. Les modes d’écriture vous y conduisent déjà : l’appel d’annonce d’Amazon traite un article à la fois, eBay fonctionne par lots de 25 et les traitements en masse de Walmart passent par un flux asynchrone. Adaptez la méthode à la vitesse de vente du SKU.

Placez le balayage et le traitement événementiel dans des files d’attente distinctes, afin qu’une avalanche de nouvelles tentatives sur un canal ne retarde jamais les mises à jour déclenchées par les commandes sur les autres.

Développer votre solution ou utiliser un outil

Les outils multicanaux prêts à l’emploi conviennent aux catalogues standard présents sur deux ou trois canaux, avec des règles classiques. Un développement sur mesure devient pertinent lorsque vos règles sortent de l’ordinaire : lots et kits, plusieurs entrepôts, plafonds par canal, ou données de commandes et de stock qui doivent alimenter votre propre ERP ou système de gestion d’entrepôt.

Prévoyez le coût récurrent, pas seulement celui de la première version. Chaque canal possède son propre processus d’autorisation, ses rôles ou périmètres, ainsi que sa propre manière de signaler les erreurs, et les trois plateformes évoluent. Si vous préférez confier l’intégration à une équipe qui l’adaptera à vos règles, c’est précisément ce que Netalith réalise avec son service d’intégration marketplace pour Amazon, eBay et Walmart : annonces, stocks, commandes et suivi.

Liste de contrôle avant la mise en production

1. Créez une table de correspondance unique des SKU : SKU interne vers SKU Amazon, SKU eBay avec identifiant d’offre, et SKU Walmart.
2. Faites migrer les anciennes annonces eBay vers le modèle Inventory API.
3. Testez d’abord chaque adaptateur dans l’environnement sandbox de la plateforme. eBay et Walmart en proposent un, et l’API Listings Items d’Amazon dispose d’un sandbox statique.
4. Lancez la synchronisation avec un seuil tampon généreux, puis réduisez-le une fois que les lectures de retour ne montrent plus d’écart.
5. Déclenchez des alertes sur les lignes eBay rejetées et les lignes de flux Walmart en échec, pas uniquement sur les erreurs HTTP.
6. Planifiez le traitement de rapprochement avant d’en avoir besoin.

Vous avez un catalogue et des règles, mais pas le temps de développer le pipeline ? Demandez un devis gratuit en indiquant vos canaux et vos volumes pour obtenir une réponse adaptée à votre projet.