HubSpot Contact Lists API v1 Sunsets April 30, 2026 — What Breaks in n8n and How to Migrate

What actually stops working, and what quietly changes behavior instead

HubSpot's developer changelog confirms the sunset date for the v1 Contact Lists API was extended from an earlier 2025 date to April 30, 2026, to give more migration time. After that date, all but three v1 endpoints are removed and begin returning HTTP 404. The three that continue to function — get all contacts, get recently updated contacts, and get recently created contacts — are explicitly documented as no longer returning list membership information even though they keep responding. That second detail is easy to miss: a workflow calling one of those three surviving endpoints will not see an obvious error, it will just silently stop getting the list-membership data it used to depend on.

This matters specifically for n8n because the built-in HubSpot node's List resource, where it exists in your installed node version, is generally understood by the n8n team itself to be built on the v1 API — an n8n GitHub issue and a related community feature-request thread both reference this same v1 sunset directly, treating it as something the HubSpot node needs to account for.

If your n8n workflow reads a static list's members to trigger downstream actions (a nightly export, a nurture sequence, a sync to another tool), and it does so through the HubSpot node's List operation rather than a raw HTTP Request node hitting v3 endpoints directly, it is very likely on the affected path and needs to be re-pointed before the deadline — not urgently broken today, but on a fixed clock.

Confirm whether your workflows are actually exposed

Check every n8n workflow that touches HubSpot lists for two things: which node performs the list operation, and which underlying endpoint it calls. If it's the built-in HubSpot node's List resource, check your n8n version's release notes or the node's current documentation for whether it has already been updated to call v3 endpoints — this is exactly the kind of breaking dependency change a node maintainer would need to ship ahead of the sunset date, and the timeline of that update matters more than the general "is my n8n up to date" question.

If the workflow instead uses an HTTP Request node calling a URL under `/contacts/v1/lists/...`, that is unambiguously the old API and will 404 after the deadline regardless of what the HubSpot node does. Search your workflow's HTTP Request node URLs directly for the string `/v1/lists` or `/contacts/v1/` to find these quickly across a large workflow library.

Workflows that only read a list's contacts via the three surviving read endpoints (all contacts, recently updated, recently created) will keep running without an error, but should still be checked for whether they were relying on those endpoints specifically for list-membership data — since that part of the response goes away even though the endpoint itself does not 404.

• Built-in HubSpot node, List resource — check whether your n8n version's node has already migrated to v3.
• HTTP Request node calling `/contacts/v1/lists/...` — will 404 on or after April 30, 2026, guaranteed.
• HTTP Request node calling one of the 3 surviving v1 read endpoints — keeps responding, but loses list-membership data.
• Any workflow using v3 Lists endpoints already (`/crm/v3/lists/...`) — not affected by this sunset.

Mapping the common v1 operations to their v3 equivalents

The v3 Lists API is not a drop-in URL swap — it uses a different membership model and, for static lists specifically, a different way of adding and removing records. HubSpot's own v1-to-v3 migration guide is the authoritative source for the full endpoint mapping; the table below covers the operations that show up most often in n8n workflows.

Rebuilding the pattern in n8n with the HTTP Request node

Until (or unless) your n8n version's built-in HubSpot node exposes v3 list membership operations directly, the practical path is an HTTP Request node using the same private-app or OAuth credential already configured for other HubSpot nodes in the workflow, pointed at the v3 endpoint and body shape from the table above.

Because v3 membership operations return record IDs rather than full records, most workflows need an additional step after fetching membership: a batch read call (see the batching guide on this site for how to do that efficiently) to turn a list of IDs into full contact, company, or deal records with the properties your downstream logic actually needs.

Test the add/remove operations against a disposable test list before pointing them at a real marketing or sales list — the array-in-request-body format is a common source of a silent no-op if the body is malformed, since some malformed v3 requests return a success-looking response without actually changing membership.

PUT https://api.hubapi.com/crm/v3/lists/{listId}/memberships/add
Body: ["51424", "51425", "51426"]   // array of record IDs as strings

Then, to get full contact data for those same IDs:
POST https://api.hubapi.com/crm/v3/objects/contacts/batch/read
Body: { "inputs": [{"id":"51424"}, {"id":"51425"}, {"id":"51426"}], "properties": ["email","firstname","lastname"] }

Active (smart/dynamic) lists behave differently in v3 — don't assume the same pattern

A static list's membership in v3 is something your workflow explicitly adds to and removes from, using the endpoints above. An active list's membership is computed by HubSpot from the list's filter criteria and cannot be modified directly through the membership add/remove endpoints — attempting to add a record to an active list via the API will fail or be rejected, because membership is derived, not assigned.

If a workflow currently manages what looks like list membership but the list is actually an active/smart list in HubSpot, the correct v3 approach is reading its computed membership (the same GET memberships endpoint works for reading), not attempting to add or remove records from it. Confirm the list type using the "get all lists" endpoint before assuming which membership model applies.

Timeline for the migration itself

Do not wait until close to April 30, 2026 to start. Inventory affected workflows now, since the audit step (searching every workflow's URLs and node configurations) can be done well ahead of any code changes and surfaces the true scope of the work. Build and test the v3 replacement for one workflow first, verify it end to end including the add/remove behavior against a disposable test list, then apply the same pattern to the remaining affected workflows.

Keep the old v1-based workflow deactivated rather than deleted until the v3 replacement has run successfully in production for at least one full cycle of whatever the workflow's normal schedule is — this gives you a rollback path if the v3 replacement has a data-shape issue that only shows up with real production data.

Verification checklist

• Searched every n8n workflow's HTTP Request URLs and HubSpot node configuration for v1 list dependencies.
• Confirmed whether the installed n8n HubSpot node version already migrated its List resource to v3.
• Rebuilt add/remove/read operations against the v3 endpoints and array-in-body request format.
• Confirmed each affected list's type (static vs active) before assuming the add/remove pattern applies.
• Tested against a disposable list before pointing the new workflow at a real production list.
• Kept the old workflow deactivated (not deleted) until the v3 replacement proved out in production.

Sources checked for this guide

The sunset date, surviving endpoints, and their behavior change come directly from HubSpot's developer changelog and its official v1-to-v3 Lists API migration guide. The n8n-specific exposure (built-in HubSpot node relying on v1) comes from an n8n GitHub issue and community feature-request thread referencing the same sunset.