Is Your Webflow Integration Still on the v1 API?

Is your Webflow integration still running on the v1 API?

If nobody has touched it since 2024, quite possibly. Webflow's own deprecation notice sets 31 March 2025 as the deprecation date for the v1 API and says that while v1 may continue to function after this date, it will no longer receive maintenance, updates, or support. Working and supported are not the same thing.

That is a quietly awkward situation for a lot of B2B sites. The form handler still posts, the CRM sync still runs, nothing is broken, and so nothing gets looked at. Meanwhile the thing it depends on has been unmaintained for over a year.

This is a practical audit: how to find out what you are still running, what actually changes on v2, and which integrations deserve attention first.

What actually happened to the Webflow v1 API?

It was wound down on a published timeline. Webflow's deprecation notice gives two dates: 1 August 2024 for the de-listing of Marketplace Apps still reliant on v1, and 31 March 2025 as the deprecation date for the v1 API itself.

Webflow's wording after that date is careful. The notice says v1 may continue to function but will no longer receive maintenance, updates, or support, and tells developers to start your migration as soon as possible to ensure uninterrupted service. That is a vendor telling you the lights are still on and nobody is home.

The guidance is specific about what to move to. Webflow directs developers to use v2 API Site Tokens for new integrations instead of v1 tokens, to register v2 webhooks to continue receiving real-time notifications, and to adopt the v2 App registration process for new applications.

Why is a working deprecated API still a problem?

Because the failure, when it comes, arrives without warning and without a fix. An unmaintained endpoint does not get patched, does not get a migration window, and does not get a status page entry written for your benefit. The first signal is usually a client asking why leads stopped arriving.

The second reason is that nobody owns it. Deprecated integrations tend to be the ones built by someone who has left, documented nowhere, and holding a credential nobody can rotate. The technical risk and the organisational risk arrive together.

We treat this the same way we treat any unmaintained dependency: the question is not whether it works today but what the recovery plan is when it stops. If the answer is a shrug, that is the finding. An abandoned dependency poses the same question, and the answer is rarely to leave it alone.

How do you find out what is still on v1?

Start with the credentials, not the code. Every integration needs a token, so list every Webflow token that exists, which workspace or site it belongs to, and what holds it. A token nobody can account for is your first finding.

Then look at the call targets. v2 endpoints live under the v2 path, so any integration pointing at an older path is the thing you are looking for. Checking the base URL in each script, Zap, or serverless function is a mechanical job that usually takes an afternoon.

Finally check your webhooks separately, because they are easy to forget. Webhooks are registered server side rather than living in your codebase, so a webhook created three years ago is invisible to a code search. List them from the API rather than from memory.

What changes when you move to v2 tokens?

Mostly the permission model, and it is stricter in useful ways. v2 separates what a token can do into scopes, and some capabilities are deliberately closed to simple tokens altogether.

The custom code API is the clearest example. Webflow's documentation states that only Webflow Apps with OAuth tokens can call the custom code API endpoints, not clients with site or Workspace tokens. If your integration touches custom code, a token swap is not enough and you need an App.

Scopes also mean you have to say what you need. The custom code endpoints, for instance, require sites read and write, pages read and write, and custom code read and write. That is more setup than a single all-powerful key, and it is the right trade: a leaked narrow token does less damage. Our notes on the Webflow Data API cover the wider surface.

What do v2 webhooks do differently?

They are signed, limited, and they give up. Webflow's webhook documentation describes a request signature formatted as a SHA-256 HMAC hash, using either the site token secret or the OAuth app's client secret as the signing key.

Verification has three parts in Webflow's description: build an HMAC hash by concatenating the timestamp and request body with a colon separator, compare it against the x-webflow-signature header, and check that the request timestamp is not older than 5 minutes. If your handler skips that last step, a captured request can be replayed at you later.

The retry behaviour is the detail most likely to bite. Webflow says any response other than a valid HTTP 200 is regarded as a failure, and that it retries up to three times at 10 minute intervals before marking the webhook as failed and deactivating it. A deactivated webhook does not come back on its own. Our notes on verifying webhook signatures cover the handler side properly.

What are the v2 rate limits?

Plan dependent, and lower than people assume. Webflow's rate limit reference gives 60 requests per minute on Starter and Basic, 120 per minute on CMS, eCommerce, and Business, and custom limits on Enterprise.

Exceeding the limit returns HTTP 429 Too Many Requests, and Webflow's documentation notes the response includes a Retry-After header indicating how long to wait, typically around 60 seconds. An integration that ignores that header and retries immediately will simply keep failing.

These numbers matter most for bulk work. Importing a few thousand CMS items at 120 requests a minute is a scheduling problem, not a scripting one, and an integration written without backoff will hit the wall every time. Build the limit into the design rather than discovering it in production.

What does a migration actually involve?

Usually less code than you fear and more inventory than you expect. The endpoint shapes changed, so request and response handling needs updating, but the hard part is finding every caller and knowing what each one is for.

Work integration by integration rather than all at once. Pick the one that touches customer data first, get it onto a v2 token with the narrowest scopes that work, verify it end to end, then move on. A half-migrated system where you know exactly what is left is in better shape than a big-bang attempt that stalls.

Leave the webhooks for a deliberate pass of their own. Because they live server side and have their own signing and retry behaviour, migrating them is a different job from migrating API calls, and treating it as one task is how a webhook ends up quietly deactivated.

Which integrations are riskiest to leave alone?

Anything on the path between a form and a human. A form that posts to a CRM is the integration whose failure costs real money and gets noticed last, because nobody monitors the absence of leads as carefully as they monitor an error. Our notes on getting Webflow form data into a CRM cover that path in detail.

Next are the ones that write content. A sync that creates or updates CMS items can fail in a way that leaves half a collection stale, and stale content is harder to spot than missing content. These also tend to be the ones that run on a schedule nobody remembers setting.

Lowest risk are the read-only reporting integrations. If a dashboard breaks, someone complains the same day and nothing is lost. That is the sort of thing to migrate last, deliberately, rather than by accident.

How do we handle this on inherited sites?

We inventory before we touch anything. The first deliverable on an inherited Webflow site is usually a list: every token, every webhook, every scheduled job, and what each one talks to. That list is often the first time anyone has seen the whole picture.

Then we rank by what a failure would cost rather than by how old the code is. An ancient script that posts to a Slack channel can wait. A three year old function that is the only route from a demo request to the sales team cannot.

We are also honest with clients that this work is unglamorous and shows up in no metric. Nothing looks better after it. The payoff is that a quiet failure becomes impossible rather than inevitable, and that is worth saying out loud before the invoice. Our notes on auditing an inherited Webflow site cover the rest of that first pass.

What should you do before the next deprecation?

Write down what you depend on. The reason the v1 wind-down caught so many teams is not that the notice was unclear, it is that nobody had a list of integrations to check it against. A one page inventory, kept current, turns every future deprecation notice into a ten minute task.

Our bet is that this gets more important rather than less, because the number of moving parts attached to a modern marketing site keeps growing. Tokens, webhooks, Apps, scheduled jobs, and third party automations all age, and none of them announce it.

If you suspect something on your site is running on a credential nobody owns and an API nobody maintains, we are happy to go looking with you. Find us at phoenix.studio.