The Legacy Unsubscribe API endpoints are sunset from November 1, 2026. After that date, calls made to these endpoints no longer function, so every flow still using them — your own code, Zapier, Make, n8n — has to point at the v2 multichannel unsubscribe endpoints to keep working without disruption. This article maps each legacy route to its replacement, lists the response changes that can break your existing code, and covers the new contact-level and bulk routes.

The unsubscribe feature was originally developed when email was the only channel available on lemlist. With several channels now available, the unsubscribe system was reworked to handle them.

That rework also introduced a way to unsubscribe at the Contact level, ensuring no future communication is sent from any channel — including any channel added to the platform later.

You need:

These five endpoints are sunset and act as direct replacements for one another. Replace the route, keep the same intent.

✅ Verify: a call to the v2 route returns 200 with the record, and the same call to the legacy route is no longer used anywhere in your flow.

These changes can break existing client code. Check each point against your current integration.

✅ Verify: nothing in your code reads email from a POST response, depends on the exact text of the DELETE response, or maps export columns by position.

Since March 30, 2026, a Contact unsubscription no longer emits emailsUnsubscribed.

Subscribe to entityUnsubscribed (whole contact) or variableUnsubscribed (single variable) instead.

You can now unsubscribe in bulk:

You also have access to new endpoints that manage unsubscribes at Contact level rather than by specific channel:

A form on your website unsubscribes people, and your script reads the email back from the response to log it.

Before: POST /unsubscribes/{email}, then read email from the response.

After: POST /v2/unsubscribes/variables/{value}, then read value. You also get variable and source back. If that value is already unsubscribed, you get the existing record with 200, so you don't need to check first.

If you want that person blocked on every channel and not just on one email address, call POST /v2/unsubscribes/contacts/{contactId} instead. This sets doNotContact on the contact.

Issue: 404 with "Variable not found" on a GET that used to succeed.

Root cause: the value is not unsubscribed, and v2 returns a 404 where your code expected the legacy response.

Fix: treat 404 as "this value is not unsubscribed" rather than as an error, and remove any read of createdAt from that response.

Issue: 409 when re-subscribing a variable.

Root cause: the variable was unsubscribed by a protected source — lead or abuse.

Fix: read the source field before attempting to re-subscribe, skip protected sources, and handle 409 without retrying.

Issue: your DELETE call fails when handling the response.

Root cause: the response is currently the plain string "Variable subscribed" rather than a JSON object, and it will become JSON in a future update.

Fix: write the response handling so it accepts both a plain string and a JSON object, and never branch on the exact text. Rely on the status code instead, and expect 400 rather than 404 when the value does not exist.

Issue: the email is missing from the response after an unsubscribe.

Root cause: the email field was removed from the POST variable response.

Fix: read value instead.

This change takes some work to put in place on your end, so reach out to support or your assigned Account Manager if you need extra help.