Mise à niveau de l'API
Comment votre version d'API est choisie, et comment passer à une version plus récente.
Les versions de l'API sont identifiées par date : votre compte est fixé sur une version, et une
requête peut en demander une autre avec l'en-tête X-Wajub-Version. Versionnage
liste les versions prises en charge ; une version absente de cette liste reçoit une réponse 400.
Un nouveau champ ne crée pas une nouvelle version
L'ajout de champs à une réponse, de nouveaux endpoints et de nouvelles valeurs d'énumération ne change pas la version. Analysez les réponses de façon à ignorer un champ inconnu. Traitez un statut inconnu comme non définitif au lieu de provoquer une erreur.
Sélection de votre version
Trois sources sont examinées. La première correspondance l'emporte.
- 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
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
La version par défaut de la plateforme
Il s'agit de la version actuelle, soit
2026-10-11aujourd'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.xxxxxxxxxxxxxxxx…" \
-H "X-Wajub-Version: 2026-08-01" \
-D -Un en-tête mal formé est ignoré, pas refusé
Un en-tête qui ne respecte pas exactement le format YYYY-MM-DD, comme 2026-8-1 ou v2, est
ignoré et la version de votre compte s'applique. Vérifiez l'en-tête de réponse au lieu de supposer
que celui de la requête a été accepté.
Passer à une version supérieure
- 1
Lisez ce qui change
Le journal des modifications liste ce que change chaque version. Recherchez dans votre code les noms de champs qu'il présente, dans les deux directions.
- 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
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
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.
Comparez les payloads au lieu de deviner
Konsole enregistre la version résolue avec le corps de la requête. Vous pouvez ainsi comparer deux appels utilisant deux versions dans Journaux API.
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 une réponse 400 au lieu d'une
rétrogradation silencieuse. Ce choix évite de modifier vos payloads sans vous prévenir.