Versionnement

Deux versions distinctes

• La version du contrat HTTP est le /v1 des chemins. Elle ne bouge pas quand cette documentation est republiée.
• La version du document, visible dans info.version de la spécification OpenAPI, est une date. Elle change à chaque publication.

Ce qui peut changer sans préavis

Traitez ces évolutions comme normales, et écrivez votre client pour qu'il les absorbe :

• Un champ ajouté dans une réponse. Ne rejetez pas une réponse qui porte des champs que vous ne connaissez pas.
• Un champ ajouté dans le corps du webhook sortant. Il entre dans la chaîne signée : votre vérificateur doit parcourir le corps reçu, jamais une liste de champs codée en dur, sinon un ajout casse la vérification de signature. Ces ajouts sont annoncés dans le changelog, mais ne déclenchent pas de /v2.
• Une valeur ajoutée à une énumération : un nouveau statut, une nouvelle catégorie d'échec, un nouveau workflowType. C'est la raison pour laquelle Statuts publie une partition et non une liste — écrivez un default dans vos switch.
• Un nouvel opérateur, un nouveau pays, une nouvelle devise. Lisez-les de GET /v1/corridors/available, ne les codez pas en dur.
• Le texte d'un message d'erreur. Voir Erreurs.

Ce qui déclencherait un /v2

• Le retrait ou le renommage d'un champ de requête ou de réponse.
• Le changement de sémantique d'un statut existant.
• Le changement d'unité ou de type d'un champ existant.

Ces changements ne seront pas faits sur /v1.

Comment suivre

Le changelog de l'API est le seul canal. Le dépôt étant privé, l'historique des commits ne vous est pas accessible : ne comptez pas dessus.