Gestion des versions et obsolescence
La v3 est l’API actuelle. La 2.1 est maintenue à ses côtés, et non progressivement abandonnée. Cette page indique ce qui est stable, par quoi un champ a déjà été remplacé, et où trouver les deux choses que la 2.1 fait encore et que la v3 ne fait pas.
La v3 est l’API actuelle
La v3 est l’API que cette référence documente en premier, et celle sur laquelle les nouvelles intégrations doivent s’appuyer. Ce n’est ni une préversion ni une release candidate — c’est la surface actuelle et prise en charge.
La 2.1 est maintenue, pas retirée
L’API 2.1 est maintenue en parallèle de la v3. Elle n’est ni obsolète ni en fin de vie : c’est l’API à utiliser quand votre intégration a besoin de quelque chose que la v3 n’expose pas encore.
Le champ email de premier niveau est obsolète
Au sein même de la v3, un champ a déjà été remplacé : le champ email de premier niveau, à la création et à la mise à jour d’un conteneur, est obsolète au profit de sender.email. Les deux sont encore acceptés, mais les nouvelles intégrations doivent envoyer sender.email et non le champ de premier niveau.
Les anciens alias de contact restent reconnus
En plus des objets typés sender et recipient, un ensemble d’alias historiques dans additionalData — email, senderEmail, des variantes du nom de l’expéditeur, receiverEmail, receiverPhone, messageNotified — reste reconnu, et résolu après les champs typés et le champ email de premier niveau obsolète.
Ce que cette page ne dit pas
Aucune politique d’obsolescence datée n’est publiée à ce jour, pour l’une ou l’autre API.