Les anciennes routes de l’API de désabonnement seront désactivées à partir du 1er novembre 2026. Après cette date, les appels à ces routes ne fonctionneront plus. Pour éviter toute interruption, tous les processus qui les utilisent encore (votre propre code, Zapier, Make, n8n) doivent donc passer aux routes v2 de désabonnement multicanal. Cet article présente l’équivalent de chaque ancienne route, les changements dans les réponses qui peuvent empêcher votre code de fonctionner et les nouvelles routes de désabonnement par contact et en masse.

La fonctionnalité de désabonnement a été conçue à une époque où l’email était le seul canal disponible sur lemlist. Avec l’arrivée de nouveaux canaux, le système de désabonnement a été revu pour les prendre en charge.

Cette refonte permet aussi de désabonner un contact, tous canaux confondus. Aucune communication ne lui sera alors envoyée, y compris sur les canaux qui seront ajoutés à la plateforme par la suite.

Il vous faut :

Ces cinq anciennes routes vont être désactivées. Remplacez chacune par son équivalent direct en v2 : l’action reste la même.

✅ À vérifier : l’appel à la route v2 renvoie l’enregistrement avec le code 200, et l’ancienne route correspondante n’est plus appelée nulle part dans votre processus.

Ces changements peuvent empêcher votre code client de fonctionner. Vérifiez votre intégration actuelle point par point.

✅ À vérifier : votre code ne lit pas le champ email dans une réponse POST, ne dépend pas du texte exact de la réponse DELETE et ne se base pas sur la position des colonnes de l’export.

Depuis le 30 mars 2026, le désabonnement d’un contact ne déclenche plus l’événement emailsUnsubscribed.

Abonnez-vous plutôt à entityUnsubscribed (contact, tous canaux confondus) ou à variableUnsubscribed (une seule variable).

Vous pouvez désormais désabonner des variables en masse :

Vous avez aussi accès à de nouvelles routes pour gérer les désabonnements au niveau du contact, plutôt que pour un canal précis :

Un formulaire sur votre site internet permet de se désabonner. Votre script récupère l’adresse email dans la réponse pour la journaliser.

Avant : vous appeliez POST /unsubscribes/{email}, puis lisiez le champ email dans la réponse.

Après : appelez POST /v2/unsubscribes/variables/{value}, puis lisez le champ value. La réponse contient aussi variable et source. Si cette valeur est déjà désabonnée, l’API renvoie l’enregistrement existant avec le code 200 : vous n’avez donc pas besoin de vérifier son statut au préalable.

Si vous souhaitez bloquer toute communication avec cette personne sur tous les canaux, et pas seulement pour une adresse email, appelez plutôt POST /v2/unsubscribes/contacts/{contactId}. Cet appel active l’indicateur doNotContact sur le contact.

Problème : une requête GET qui fonctionnait auparavant renvoie 404 avec "Variable not found".

Cause : la valeur n’est pas désabonnée. La v2 renvoie donc un code 404, alors que votre code attendait la réponse de l’ancienne API.

Solution : traitez 404 comme l’indication que cette valeur n’est pas désabonnée, et non comme une erreur. Ne lisez plus createdAt dans cette réponse.

Problème : vous obtenez 409 lors du réabonnement d’une variable.

Cause : la variable a été désabonnée par une source protégée : lead ou abuse.

Solution : lisez le champ source avant de tenter un réabonnement, excluez les variables dont la source est protégée et gérez le code 409 sans relancer la requête.

Problème : votre appel DELETE échoue au moment de traiter la réponse.

Cause : la réponse est actuellement une simple chaîne de caractères, "Variable subscribed", et non un objet JSON. Elle passera au format JSON lors d’une prochaine mise à jour.

Solution : adaptez le traitement de la réponse pour accepter aussi bien une simple chaîne de caractères qu’un objet JSON. Ne faites jamais dépendre la logique de votre code du texte exact de la réponse. Appuyez-vous plutôt sur le code de statut : si la valeur n’existe pas, vous recevrez 400 au lieu de 404.

Problème : l’adresse email n’apparaît plus dans la réponse après un désabonnement.

Cause : le champ email a été supprimé de la réponse à la requête POST sur une variable.

Solution : lisez value à la place.

Cette migration demande un peu de travail. Si vous avez besoin d’aide supplémentaire, contactez l’équipe support ou votre responsable de compte attitré.