Gestion des versions

L'API Wajub est versionnée par date. Votre compte est fixé sur la version en vigueur au moment de sa création, et un changement cassant sort sous une nouvelle date sans toucher à votre intégration. La version actuelle est la 2026-10-11.

Versions prises en charge

Les nouveaux comptes sont fixés sur 2026-10-12 ; un compte existant garde sa version et obtient une version plus récente avec l'en-tête X-Wajub-Version. Les webhooks suivent la version actuelle. Le journal des modifications indique ce que change chaque version.

Une version reste prise en charge au moins six mois après avoir été remplacée, et son retrait est annoncé avant d'avoir lieu. Une version annoncée est servie à qui la demande avec l'en-tête, pour l'essayer avant qu'elle devienne actuelle ; aucun compte n'y est déplacé.

Choisir une version

Trois sources sont consultées, dans cet ordre : l'en-tête X-Wajub-Version de la requête, la version fixée sur votre compte, puis la valeur par défaut de la plateforme.

Authorization: sk.xxxxxxxxxxxxxxxx...
X-Wajub-Version: 2026-08-01

L'en-tête n'est pris en compte que s'il correspond à YYYY-MM-DD. Toute autre valeur, un v2, un latest, une chaîne vide, est ignorée en silence et c'est la version de votre compte qui s'applique. Une date bien formée qui ne figure pas dans la liste des versions prises en charge provoque une erreur franche :

Depuis un navigateur, une page peut envoyer X-Wajub-Version avec une clé publique : la requête préliminaire l'accepte, et le 400 ci-dessus porte les en-têtes CORS. La page lit donc le message au lieu d'une erreur CORS.

Chaque réponse indique la version qui a répondu

X-Wajub-Version revient dans chaque réponse, y compris les erreurs et le 400 ci-dessus, et le code d'une page peut le lire. Enregistrez-le dans vos logs : c'est le moyen le plus rapide de découvrir qu'un service oublié est encore fixé sur une ancienne date.

curl -i https://api.wajub.com/transfers/po_225KMKULRQqYvlhrgUOE \
-H "Authorization: $WAJUB_API_KEY" \
-H "X-Wajub-Version: 2026-08-01"

La conversion se fait dans les deux sens

Fixer une version garde tout le contrat de cette version, dans les requêtes comme dans les réponses.

Ce qui compte comme un changement cassant

Un changement de sécurité sur ce qu'une clé atteint ou lit fait exception : il s'applique à toutes les versions à la fois, et le journal des modifications le signale là où il se produit.

Passer à une nouvelle version

1. 1

   Lisez ce qui a changé

   Le changelog détaille les différences de chaque date, champ par champ.

2. 2

   Testez avec l'en-tête

   Envoyez X-Wajub-Version avec la nouvelle date en utilisant une clé sandbox. Rien ne change sur votre compte : vous pouvez faire tourner ce test en parallèle de votre intégration actuelle aussi longtemps que nécessaire.

3. 3

   Déployez service par service

   Gardez l'en-tête pendant le déploiement, un service à la fois. Un service que vous n'avez pas migré continue de répondre sur l'ancienne date.

4. 4

   Fixez le compte, retirez l'en-tête

   Une fois que tout tourne sur la nouvelle date, demandez au support de changer la version fixée sur votre compte, puis retirez l'en-tête. Konsole → Vue d'ensemble indique sur quelle version votre compte est fixé et laquelle est actuelle, pour que vous puissiez confirmer que le changement a bien été appliqué.