Mise à niveau de l'API

Les versions de l'API sont identifiées par date. Quatre versions sont actives en même temps et un nouveau compte est fixé sur la plus récente. 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

Les changements cassants publiés sous une version figurent ci-dessous, deux sur les transferts et un sur les paiements. Les changements additifs ne créent pas de nouvelle version. Quelques changements qui cassent une intégration sont aussi sortis sans version, comme l'objet transfert remanié, des événements renommés, /accounts réservé aux clés privées et le statut de transfert review : épingler une ancienne version ne les annule pas. Le journal des modifications les liste avec leur date et l'action à mener.

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-10-11 aujourd'hui. Elle ne décide que pour un appel qui n'atteint aucun compte : tous les comptes sont fixés.

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.xxxxxxxxxxxxxxxx…" \
  -H "X-Wajub-Version: 2026-08-01" \
  -D -

Passer à une version supérieure

1. 1

   Lisez les différences

   Le tableau ci-dessus contient les changements cassants versionnés ; consultez le journal des modifications pour les autres. 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.