Ce guide explique comment l'API Merchant gère le contrôle de version, les versions et le cycle de vie de ses différentes versions.
Schéma de gestion des versions
L'API Merchant utilise une stratégie de gestion des versions au niveau des sous-API. Cela signifie que les composants ou services individuels de l'API Merchant auront leur propre cycle de vie de version.
Format et présentation de la gestion des versions
Versions stables des sous-API:si une sous-API est en version stable, toutes ses méthodes le sont également. La version stable de la sous-API est représentée par vX (par exemple, v1, v2). Il s'agit de versions majeures prêtes à être utilisées en production.
Versions alpha des sous-API:si une sous-API est en version alpha, toutes ses méthodes le sont également. La version de la sous-API alpha est représentée par vXalpha (par exemple, v1alpha, v2alpha). Il s'agit de versions expérimentales en accès anticipé destinées aux tests et aux itérations rapides. Les versions alpha ne sont pas garanties en termes de stabilité ni de durée de vie. Les versions alpha 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, de la version 1 à la version 2) : ces incréments signalent des modifications incompatibles avec les versions antérieures et destructives, qui nécessitent une action du développeur. Seuls les changements importants des sous-API stables auront un nouveau numéro de version. Par exemple, de la version v1 à la version 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 bloquants à une sous-API seront publiés dans le canal alpha de la dernière version stable ou directement dans la dernière version stable.
Couchers de soleil
Nous abandonnons régulièrement les anciennes versions de sous-API pour les marchands. Nous nous engageons à proposer 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 1 de la sous-API Products le 15 janvier 2026, elle ne sera définitivement supprimée qu'au plus tôt le 15 janvier 2027. Passée cette date, la version antérieure de la sous-API ne sera plus disponible.
Version et état du cycle de vie de la sous-API
Le tableau suivant répertorie les dernières versions de chaque sous-API de l'API Merchant:
| Sous-API | Versions alpha | Versions bêta | État |
|---|---|---|---|
| Comptes | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Produits | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Données produit | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Inventaires locaux | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Inventaires régionaux | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Sources de données | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Promotions | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Rapports | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Conversions | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Notifications | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Avis | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Paramètres de livraison | Non disponible | Version bêta v1 | La version bêta 1 de la version v1 est active |
| Product Studio | Version alpha v1 | Non disponible | La version alpha v1 est active |
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 recommandons d'utiliser la dernière version en permanence.
- Concevez votre application pour qu'elle gère correctement les diverses 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 susceptibles d'être introduits avec les nouvelles versions de 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 question concernant la feuille de route d'une sous-API, contactez-nous. Pour savoir comment contacter l'équipe Merchant API pour obtenir une assistance technique, consultez Obtenir de l'aide concernant Merchant API.