Mise à niveau de l'API

Les versions de l'API sont identifiées par date. Trois versions sont actives en même temps et la plus récente est utilisée par défaut. Pour passer de l'une à l'autre, modifiez un en-tête et appliquez les changements indiqués ci-dessous.

Toute version absente de cette liste est immédiatement refusée.

Changements réels

Il existe deux changements cassants, tous deux liés aux transferts. Tous les autres changements sont additifs et ne créent pas de nouvelle version.

Ces changements ne cassent pas les anciens clients. Si vous fixez 2025-01-01, un transfert renvoie toujours is_complete et les deux champs du registre, car la réponse est adaptée à votre version. Si vous envoyez is_complete avec une version plus récente, il est converti à l'entrée.

Sélection de votre version

Trois sources sont examinées. La première correspondance l'emporte.

1. 1

   L'en-tête X-Wajub-Version

   Il s'applique à une requête et remplace toutes les autres valeurs. Son format doit être exactement identique à 2026-09-01.

2. 2

   La version fixée sur votre compte

   Elle est définie à la création du compte ou par le support. Elle s'applique aux appels qui ne contiennent pas l'en-tête.

3. 3

   La version par défaut de la plateforme

   Il s'agit de la version actuelle, soit 2026-09-01 aujourd'hui.

Quelle que soit la source retenue, la version résolue apparaît dans le même en-tête de chaque réponse. C'est le seul moyen fiable de connaître la version réellement utilisée.

curl https://api.wajub.com/transfers/po_kZ3qP8mWvL2xR7tB \
  -H "Authorization: sk_test.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…" \
  -H "X-Wajub-Version: 2026-08-01" \
  -D -

Passer à une version supérieure

1. 1

   Lisez les différences

   Le tableau ci-dessus contient tous les changements cassants. Recherchez dans votre code les noms de champs qu'il présente, dans les deux directions.

2. 2

   Fixez la nouvelle version dans la sandbox

   Envoyez l'en-tête avec une clé de test et exécutez vos scénarios : initialisation, réussite, échec, remboursement, transfert, traitement des webhooks et pagination.

3. 3

   Pilotez l'en-tête depuis la configuration

   Utilisez une variable d'environnement plutôt qu'une valeur littérale. Un retour arrière demande alors un redémarrage plutôt qu'un déploiement.

4. 4

   Activez-la en production

   Surveillez les mêmes signaux que pour tout autre déploiement, puis retirez les branches de compatibilité lorsque les mesures restent stables.

Dans le SDK Node, les headers propres à une requête se placent dans les options avec idempotencyKey. Ajoutez-y l'en-tête de version pendant vos tests.

Politique de fin de prise en charge

La dépréciation d'une version est annoncée six mois avant son retrait de la liste des versions prises en charge. Cette annonce paraît dans le Journal des modifications. Après le retrait, les appels fixés sur cette version reçoivent la réponse 400 ci-dessus au lieu d'une rétrogradation silencieuse. Ce choix évite de modifier vos payloads sans vous prévenir.