Klaviyo retired the revision most lead-form recipes pin, and the form may not have noticed

A date on a changelog, five days ago

Klaviyo's API changelog is a list of dated revisions, and for the older ones it carries a second date. On 12 September the entry for the revision in question opened with:

Revision 2024-10-15 (GA) - Revision supported until: 2026-10-15

• Klaviyo API changelog, Klaviyo Developers, read 12 September 2026

That is 730 days, which is the policy: "Each revision is supported for 2 years after its release." For its first year a revision is "Stable", for the second it is "Deprecated", and then:

Retired - 2 years after release, the revision is no longer supported, and breakages are likely to occur in any apps/integrations that rely on it. Calls to endpoints that have been removed since this revision will receive a 410 error.

• API versioning and deprecation policy, Klaviyo Developers, read 12 September 2026

So as of last Thursday, 2024-10-15 is retired. The reason that particular revision matters more than the ones retired in July, June, May and February is who pinned it. Every request to Klaviyo's current APIs must carry a revision header - omit it and the API answers 400, 'REVISION' is a required header and must be of the format YYYY-MM-DD, before it reads the body. So every integration has a date written into it somewhere, and 2024-10-15 was the current revision for the three months in which a large share of today's lead-form automations were built. A search of public code on GitHub on 12 September found the string in 1,668 files with the word klaviyo alongside it. The revision that replaced it, 2025-01-15, appears in 262. The one that was current on the day of the search, 2026-07-15, in 834.

What the next revision requires

Klaviyo's policy for a retired revision is not a 410. It is this:

If a retired revision date is passed to the request header, Klaviyo falls forward and responds to your request with the same behavior as the next oldest revision. For example, when revision 2023-06-15 retires, the next oldest revision is 2023-07-15, and any API requests to 2023-06-15 will be served 2023-07-15.

• same page

"Next oldest" in Klaviyo's usage means the oldest revision still in support, so a request stamped 2024-10-15 is, by this rule, served as 2025-01-15. And the changelog entry for 2025-01-15 opens its list of breaking changes with the one that concerns a lead form:

Subscription endpoints required field - Calls to Bulk Subscribe Profiles and Bulk Unsubscribe Profiles now require the subscriptions field, which grants or revokes consent for the indicated message types on the specified channels, such as email or sms.

• Klaviyo API changelog, "Revision 2025-01-15 (GA)", read 12 September 2026

Bulk Subscribe Profiles is the endpoint behind "put this email on the list and give it marketing consent" - the thing a website form does through an n8n HTTP Request node, a Make "Make an API call" module or ten lines of code. On 2024-10-15 the minimum request was a profile with an email address and a relationship to a list; Klaviyo's own schema for that revision describes the email field as "the email address to subscribe", and consent for the channel followed from the identifier being present. On 2025-01-15 the same schema marks subscriptions as required on the profile, and describes email as "the email address relating to the email subscription included in subscriptions". The consent has to be spelled out:

"attributes": {
  "email": "person@example.com",
  "subscriptions": {
    "email": { "marketing": { "consent": "SUBSCRIBED" } }
  }
}

Klaviyo's policy lists "addition of a required request field" among its examples of a breaking change, and a request that fails a required-field check on these APIs gets a synchronous 400 with a code of invalid and a detail naming the field. On a form that thanks the visitor before, or regardless of, what Klaviyo answers, a 400 is a run marked failed in n8n's execution list or Make's history, and nothing else. The visitor was thanked. The list did not grow.

That is the half of the change that fails a request. The same fall-forward carries a second half, which does not, for anyone reading campaigns: the Campaigns API on 2025-01-15 restructured the send-strategy fields, and a connector that still expects the old names, as the pull request against one open-source data-integration connector put it on 4 September, finds they "would silently come back null while the real data lands under new names". Bulk Unsubscribe gets the same required field as Bulk Subscribe. Two flow endpoints move from offset to cursor pagination.

Retired is not the same as switched off

All of the above is what the policy says. Here is what the API did, on 12 September, on the one endpoint of this family that answers without an API key.

POST /client/subscriptions/ is the client-side subscribe endpoint, and it checks the revision header before it checks anything else. Sent with revisions that were retired between fifteen and twenty-three months earlier - 2022-10-17, 2023-01-24, 2023-02-22 and 2023-06-15 - it did not fall forward. It answered with the validation errors of its own old schema, the one that predates a restructuring Klaviyo shipped in 2023-07-15: 'list_id' is a required field for the resource 'subscription'. Revisions from 2023-07-15 onwards took a different code path. Adding the header Klaviyo documents for opting out of fall-forward, X-Klaviyo-Revision-Fall-Forward-Opt-Out: 1, which the policy says will "result in a 410 error", changed nothing: the same old schema, no 410.

The server-side Bulk Subscribe endpoint that a form automation uses answers 401 to a bad key before it validates anything, so its behaviour on a retired revision cannot be observed without an account, and its behaviour after 15 October could not be observed at all when this was written. Klaviyo describes fall-forward as "a best-effort attempt to honor your request and not fully break your integration", which reserves the right to do it at any time.

So if a form pinned to 2024-10-15 has kept working since Thursday, that is evidence only that Klaviyo has not yet applied the policy to that request, and the policy is the only statement Klaviyo makes about what will happen next. The retirement did not change what a request gets back. It removed the promise about what it gets back.

Where the string is

Klaviyo does tell people. The notice goes to the account owner, and it goes early: in the weeks before the first revision of this API family retired in October 2024, an account owner posted the notification to Klaviyo's community, and it read, in part, "You are calling at least one API revision that will be retired in less than 6 months [...] In many cases, this is a one line code change, but could require more work in the case of breaking changes between revisions." The replies were from people in the same position - "I'm not a developer and need some serious help here" - and one whose dashboard by then showed nothing left to update and who was "still receiving a notification from Klaviyo, which doesn't inspire confidence".

Where it is, as of 12 September:

• One open-source data-integration platform's Klaviyo source connector was still on 2024-10-15. An issue asking for the bump had been open since September 2025 and was closed in June without a change; the pull request that finally makes it was opened on 4 September with a hard upgradeDeadline of 14 October in its metadata and was not merged eight days later.
• One product-analytics platform's own coding agent found revision: 2024-10-15 hard-coded in both of its Klaviyo destination templates in June - "hard-coded when the templates were first added and was never bumped" - and opened a pull request. It was closed as stale on 28 July without being merged, and a month and a half later both templates still carried the date. A separate component of the same product, the warehouse import source, was re-pinned to 2026-07-15 in July.
• A recipe on n8n's community forum, posted on 5 January 2026 as a "better alternative" for a user who said "I am not a developer btw", is an HTTP Request node to Bulk Subscribe Profiles with the header revision: 2024-10-15 and a body with no subscriptions field. It is the exact request this article is about, published nine months before the retirement. n8n has no Klaviyo node of its own - none in its node list when this was written - so every n8n workflow that talks to Klaviyo is an HTTP Request node with a revision typed into it. Two Klaviyo templates on n8n's own template site, published in May 2026, carry 2024-02-15, a revision that had already been retired for nearly three months when they went up.
• The Klaviyo SDKs pin a revision per major version. Klaviyo's Python package at versions 14, 15 and 16 is 2024-10-15; 17 is 2025-01-15, and it is 17's changelog that records the subscriptions change as "Breaking".

Make announced its own 15 October

Make's Klaviyo app does not expose a revision, so its users had no string to search for. Instead, on a documentation page updated on 23 July, Make wrote:

On October 15th, 2026, Make will update the Klaviyo app with new versions of the following modules to match changes in Klaviyo's API. These modules still work for now and are labeled Deprecated in the Scenario Builder.

• Klaviyo, Make app documentation, page updated 23 July 2026, read 12 September 2026

The first module in its table is "Add or Subscribe Profiles to a List", and the first row of that table is the change above in Make's words: "The Attributes and Subscriptions collections are now required when subscribing (previously optional)", with the instruction "Fill in both collections in the new module. Scenarios that left them empty need values before they can run." A new "Historical Import" boolean is required as well - "Set it to No for normal use". The other five modules in the table are the campaign ones, and their rows describe the send-strategy restructuring.

Which is to say Make read the same changelog and picked the same date. What the page does not say is what a scenario still on the deprecated module does after that date - whether it stops, or keeps running on whatever Klaviyo returns for the old request. The announcement appears only on that page; Make's release notes for 2026, 79 entries to 11 September, do not mention Klaviyo once, and neither did its community forum.

Zapier's Klaviyo app carries its revision internally and its help centre does not name it. A Zap using the app's own "Subscribe Profile" action has nothing to check; a Zap using the "API Request (Beta)" action with a hand-typed revision header is in the same position as an n8n node.

The dashboard, then the header

The first check is Klaviyo's, and it is the only one that answers for every integration at once. In the Klaviyo account's Developer Dashboard - one user in 2024 gave the path as Account → Integrations → Developers → Developer Tools → API Revisions - the API revisions pane counts calls by revision status - Klaviyo's page on it describes a "Retired revisions" counter, a "Deprecated revisions" counter with an "Action recommended" flag, and a "Stable revisions" counter. A non-zero number under Retired is the finding, and the API logs on the same dashboard, filtered by revision, show which private key (truncated) sent the calls, for the last fourteen days.

Then, for each integration the dashboard points at:

1. Find the string. In an n8n HTTP Request node it is in the Headers section; in Make's "Make an API call" module, in the headers list; in code, a search for revision finds it. Anything dated 2024 is retired. 2025-01-15 is next: its two years end on 15 January 2027, 87 days from today.
2. Move to the current revision, not the next one. Klaviyo's own advice is to "connect your apps to our latest revision every 12-18 months"; the current one when this was written was 2026-07-15, and Klaviyo's rhythm since 2025 has been a new revision on the 15th of January, April, July and October, so check the changelog for a 2026-10-15. Jumping to 2025-01-15 because it is the smallest step clears this cliff and lands 87 days before the next.
3. Add subscriptions to every Bulk Subscribe and Bulk Unsubscribe body. The shape is above. If the form also collects a phone number, the sms channel needs its own marketing consent; if the request is a historical import, consented_at is allowed, and otherwise it is an error.
4. Test on one address, and read the right signal. Bulk Subscribe is asynchronous: the API answers 202 when it has accepted the job, not when the profile is on the list. A developer on Klaviyo's community in 2024 got "an empty response, as expected, and it comes with a 202 response, as expected" and no change on the profile; the test had been hitting a different account. The proof is the profile appearing on the list in Klaviyo, not the status code. The test creates a real profile, so use an address you can delete.
5. In Make, replace the modules labelled Deprecated with the versions the migration table describes, fill in Subscriptions, set Historical Import to No, and re-map List ID to its new top-level field.

If the dashboard shows retired calls, finding the integrations and re-pinning them is an afternoon with a fixed price, most often as an n8n or a Make repair. Whether the form is failing at all is a question for the dashboard; whether it is failing under a promise stopped being one on Thursday.

Sources

• Klaviyo API changelog - Klaviyo Developers, read 12 September 2026. The "supported until: 2026-10-15" line, the "supported for 2 years" statement, the list of revisions with 2026-07-15 as the latest, and the breaking-changes section of Revision 2025-01-15.
• API versioning and deprecation policy - Klaviyo Developers, read 12 September 2026. The Stable, Deprecated and Retired phases, the fall-forward paragraph with its example, the opt-out header and its 410, "best-effort attempt", the breaking-change examples, and the 12-18 month advice.
• Monitor API usage - Klaviyo Developers, read 12 September 2026. The Retired, Deprecated and Stable revision counters and the "Action recommended" flag.
• Bulk Subscribe Profiles - Klaviyo API reference, read 12 September 2026 at the 2024-10-15 and 2025-01-15 revisions. The subscriptions field marked required on the later page and not on the earlier one.
• klaviyo/openapi, openapi/stable.json - read 12 September 2026 at commits 023d5a38b9 (7 January 2025, version 2024-10-15) and b3f73b9c30 (15 January 2025, version 2025-01-15). The required: ["subscriptions"] on the profile attributes in the later commit and its absence in the earlier one, and the two descriptions of the email field.
• klaviyo-api-python CHANGELOG - read 12 September 2026. Version 17.0.0 as revision 2025-01-15 with the subscriptions change marked Breaking; 14 to 16 as 2024-10-15.
• POST https://a.klaviyo.com/client/subscriptions/ - Klaviyo API, queried 12 September 2026 with 22 combinations of revision header and the opt-out header, without an API key. The invalid_revision response with no header, the old-schema validation errors on four retired revisions, the unchanged response with the opt-out header, and the different code path from 2023-07-15 onwards. The server-side Bulk Subscribe endpoint answered 401 to every variant, before validation.
• How to resolve this notification - Klaviyo Community, September-October 2024, read 12 September 2026. The text of the "[ACTION Required]" email and the replies quoted. profile-subscription-bulk-create-jobs endpoint has no effect on profile, June 2024, read the same day, for the 202 observation.
• Klaviyo - Make app documentation, page updated 23 July 2026, read 12 September 2026. The "Migrate to the new Klaviyo modules" section and its tables. Make's 2026 release notes and community forum, searched the same day, contain no mention of the change.
• Add new profile to Klaviyo list - n8n community, 5 January 2026, read 12 September 2026. The reply with the revision: 2024-10-15 Bulk Subscribe recipe without subscriptions. n8n's node list (docs.n8n.io/llms.txt and the packages/nodes-base/nodes directory on master), read the same day, has no Klaviyo node; templates 15940 and 15552 on n8n.io carry revision: 2024-02-15.
• One open-source data-integration connector's issue and pull request for the Klaviyo revision bump, read 12 September 2026 through the GitHub API - the issue's history (closed 23 June 2026 as a duplicate of an internal ticket), the pull request's upgradeDeadline: 2026-10-14, and the "silently come back null" sentence; given without the project's name
• One product-analytics platform's pull request bumping its Klaviyo destination revision, opened by the project's agent on 12 June 2026 and closed as stale on 28 July 2026 without merging, read 12 September 2026 through the GitHub API - "hard-coded when the templates were first added and was never bumped"; the template file on master, read the same day, still carries revision: 2024-10-15, and a separate pull request merged 17 July 2026 re-pinned the warehouse source to 2026-07-15; given without the project's name
• GitHub code search, 12 September 2026, through the GitHub API - file counts for "revision" with each revision date and klaviyo: 1,668 for 2024-10-15, 262 for 2025-01-15, 834 for 2026-07-15. Counts are of files, not repositories.
• Klaviyo integrations on Zapier and Zapier's help centre, searched for Klaviyo - read 12 September 2026. No revision named in either; the "API Request (Beta)" action.