Gestion des versions

Ce guide explique comment Merchant API gère la gestion des versions, les mises à jour et le cycle de vie de ses différentes versions.

Schéma de gestion des versions

Merchant API utilise une stratégie de gestion des versions au niveau des sous-API. Cela signifie que chaque Merchant API, par exemple Products dans Merchant API, aura son propre cycle de vie de version.

Format et présentation des versions

• Versions stables des sous-API : si une sous-API est dans une version stable, toutes ses méthodes le sont également. Une version stable de sous-API est représentée par vX (par exemple, v1, v2). Il s'agit de versions majeures prêtes pour la production.

• Versions alpha des sous-API : si une sous-API est en version alpha, toutes ses méthodes le sont également. Une version alpha de sous-API est représentée par vXalpha (par exemple, v1alpha, v2alpha). Elles contiennent des fonctionnalités expérimentales en accès anticipé destinées aux tests et à l'itération rapide. Les versions alpha ne sont pas garanties en termes de stabilité, n'ont pas de durée de vie définie et peuvent être modifiées ou abandonnées avec un préavis de 30 jours.

Modifications apportées à la version

• Incréments de version majeure (par exemple, v1 à v2) : ils signalent des modifications incompatibles avec les versions antérieures et des modifications importantes, qui nécessitent une action de la part du développeur. Seules les modifications importantes des sous-API stables auront un nouveau numéro de version. Par exemple, v1 à v2.
• Modifications mineures : les ajouts ou corrections rétrocompatibles sont présentés comme des modifications apportées à la version majeure existante. Ces modifications seront détaillées dans les notes de version de cette version majeure. Les ajouts non importants à une sous-API seront publiés sur le canal alpha de la dernière version stable ou directement dans la dernière version stable.

Règles d'abandon

Nous abandonnons régulièrement les anciennes versions de sous-API Merchant. Nous nous engageons à respecter une période d'abandon de 12 mois pour les versions majeures stables (vX), à compter de l'annonce officielle de l'abandon.

Par exemple, si nous abandonnons la version v1 de la sous-API Products le 15 janvier 2026, elle ne sera pas abandonnée avant le 15 janvier 2027. Au-delà de cette date, l'ancienne version de la sous-API ne sera plus disponible.

Version de la sous-API et état du cycle de vie

Le tableau suivant répertorie les dernières versions de chaque sous-API de Merchant API :

Bonnes pratiques

• Consultez régulièrement les notes de version et les dernières mises à jour pour connaître les nouvelles versions, les mises à jour majeures, les améliorations et les annonces concernant les lancements et les abandons de sous-API.
• Si une sous-API comporte deux versions stables ou plus, nous vous suggérons d'utiliser la dernière version à tout moment.
• Concevez votre application de manière à gérer correctement les différentes erreurs de sous-API, y compris les problèmes de réseau, les limites de débit et les nouveaux codes ou messages d'erreur qui peuvent être introduits avec les versions plus récentes des sous-API.
• N'attendez pas qu'une version de sous-API soit sur le point d'être abandonnée pour commencer à planifier votre mise à niveau. Commencez à évaluer et à tester les nouvelles versions dès qu'elles sont disponibles.
• Pour toute demande de fonctionnalité ou préoccupation concernant la feuille de route d'une sous-API, contactez-nous pour nous faire part de vos questions ou commentaires. Pour savoir comment contacter l'équipe Merchant API pour obtenir une assistance technique, consultez Obtenir de l'aide concernant Merchant API.