Webflow CMS API: when Webflow works as a headless CMS, and where it stops.

Is Webflow a headless CMS?

Not by design, though it can act as one. Webflow started as a visual site builder, and its CMS was built to fill Webflow pages. The Data API opened those Collections to other front ends, and a read-only Content Delivery API now serves published items from a cache, which takes most of the load off the main API.

Picture a SaaS company whose marketing site runs on Webflow and whose docs run on Next.js. Customer stories live in a Webflow Collection. With the API, the docs site can pull the same stories, render them in its own templates, and stay current when marketing edits a quote, without anyone copying text between two systems.

That's a narrower move than a full headless CMS project. As our headless CMS agency page puts it, a platform like Webflow "keeps content and design in one system." Reading its content from elsewhere splits the two again for those pages only, and whatever Webflow normally handles on them, from forms to sitemaps, becomes the other front end's job.

What can the Webflow CMS API do?

Almost everything an editor can do to an item. The API lists, reads, creates, updates, publishes, and unpublishes items, and it can write several locales in one request. A headless build leans on three parts in particular: reading published items, reading drafts for previews, and webhooks that fire when an item changes.

Field values arrive in predictable shapes. Rich text is a string that "stores long-form text with HTML formatting," so your front end styles Webflow's HTML rather than structured blocks. Images come back as objects with a file ID, a URL, and optional alt text, and reference fields return item IDs that you resolve with a second lookup.

How do caching and rate limits work?

Webflow counts Data API requests per API key: 60 a minute on Starter and Basic sites, 120 on CMS, eCommerce, and Business, custom on Enterprise. Request number 61 in a minute on a Basic site gets an HTTP 429 and a Retry-After header, usually 60 seconds. Reads served from the Content Delivery API's cache aren't counted at all.

Two details catch teams out. Premium, the plan that replaced CMS and Business for new purchases on May 13, 2026, wasn't listed on Webflow's rate-limit page in October 2026, so confirm your limit with Webflow before you size a build; our post on the Webflow price increase covers when existing sites move. And the cache cuts both ways: Webflow warns that after you update or delete a published item, the old version can persist until the cache refreshes.

A blog post that shows up four minutes late hurts nobody. A price change or a corrected legal clause is different: read those from the Data API, or refetch them from it when a webhook fires, so the cache never serves the old version.

How do you preview drafts on a headless front end?

With a preview route you build yourself. Webflow keeps two versions of each item: the staged draft editors are working on and the live version visitors see. Point a password-protected route on your front end at the staged endpoint, render it with your production templates, and editors can check a draft before it goes live.

Two rules from Webflow's docs shape how this behaves. "Updating a live item automatically updates its staged version," so a quick fix to a live item shows up in previews too. And creating items through the staged endpoints "always creates a draft," which surprises teams running imports: load 300 integration pages by script and you get 300 drafts, invisible on the front end until someone publishes them in Webflow or through the publish endpoint.

Editors notice the difference most. In Webflow, they edit a page and see it. On a headless front end, they edit fields in the CMS and open a preview link your team has to provide, which is a step back for teams used to editing on the canvas. If visual editing on the coded site is a must, a headless CMS built around it is a better fit; our headless CMS comparison covers the criteria.

How do you keep the front end in sync with Webflow?

Webflow's webhooks are the usual answer. You register a URL, and Webflow calls it whenever an item is created, edited, deleted, published, or unpublished, and after every full site publish. When an editor fixes a typo in a case study and publishes it, your server hears about it, checks that the request came from Webflow, and rebuilds that one page.

Verification is worth the few lines of code. Each request carries an x-webflow-timestamp header and an x-webflow-signature header, a SHA-256 HMAC, and Webflow suggests treating anything older than five minutes as a possible replay. Create the webhooks through the API, though: ones set up in the Webflow dashboard arrive without the headers you need to check.

Answer each delivery with an HTTP 200 straight away and do the rebuild in the background. Redirects, SSL errors, and timeouts all count as failures, and after three more attempts 10 minutes apart, Webflow switches the webhook off and sends an email. Only Webflow's support team can turn it back on, so route that email to a person, not a shared inbox nobody reads.

Watch the cache here too. If a publish webhook triggers a refetch through the Content Delivery API, the response may still be the cached version from a few minutes earlier. For webhook-driven refreshes, read the changed item from the Data API, which always returns the latest data.

What do you give up when Webflow runs headless?

Everything Webflow does for the pages it hosts. On the coded front end, there's no Designer layout, no Webflow interactions or forms, no page-level SEO settings, and no automatic sitemap. Titles, meta descriptions, canonical tags, and structured data have to come from CMS fields that your templates render, and your team owns hosting, uptime, and performance.

Rich text is a common source of surprises. It arrives as Webflow's HTML, which your front end must style, and when you write rich text through the API, code blocks are dropped: Webflow's field reference says passing them "will result in an empty string." Images uploaded through the API must be 4 MB or smaller and sit at a public URL. Our post on headless CMS SEO lists what to check before such a front end goes live.

You also run two systems instead of one. Webflow keeps its plan costs and seat management, while the front end adds a framework, a host, a deploy pipeline, and someone to maintain them. That's worth it when the second front end does something Webflow pages can't. It's a hard sell when the goal is only a faster or more custom version of the same marketing site.

When does Webflow as a headless CMS make sense?

When Webflow stays the main marketing site and the same content also has to appear somewhere else: a product's in-app help, a docs site, a partner portal, a mobile app, or one coded section of the domain. Marketing keeps one place to edit, and engineering gets clean JSON instead of scraping pages.

It makes less sense when the whole site is moving to code, when editors need visual editing on the coded pages, or when content changes many times a minute. A busy Collection with frequent writes runs into the 60 or 120 request limit quickly, while a dedicated headless CMS is built for that pattern. For hybrids that keep the front end in Webflow and add React components or a Webflow-hosted app instead, see our post on Webflow DevLink, code components, and Webflow Cloud.

We build Webflow sites and headless front ends for B2B SaaS companies, so we have an interest in the topic.

Questions about the Webflow CMS API