Webflow API vs Headless CMS: Rate Limits and Real Tradeoffs

Webflow is a visual site builder that happens to include a CMS and an API. A headless CMS, by contrast, is an API-first content store with no visual builder attached at all. The gap between the two only becomes obvious once your API traffic starts running into limits, not while you're still arranging elements on a page.

People conflate the two constantly, mostly because Webflow does expose a genuine API. But that API wasn't designed to act as the primary content backend for anything beyond the pages Webflow itself renders. This piece walks through where that API works well, and where it breaks down, along with the specific ceilings that determine which scenario applies to you.

What is Webflow's CMS, really?

Webflow's CMS revolves around collections, which are its equivalent of content types. You fill them in through the same visual editor used to lay out your pages, so content creation and page design happen inside one tool. That's the whole value proposition, and for something like a marketing site or a portfolio, it's a solid one.

The API is layered on top of that setup. It exposes collection items through REST endpoints, supporting reads and a constrained set of writes. It exists so external tools can push data into Webflow's own rendering system, not so a separate frontend, a mobile app, and an internal dashboard can all pull from a single shared source. That kind of multi-consumer setup is exactly what a headless CMS such as Draftbase is designed for from day one.

Is Webflow a headless CMS?

No. Webflow is a tightly coupled CMS that happens to expose an API. A genuinely headless CMS has no rendering layer built in at all; every bit of markup comes from whatever frontend you build yourself. Webflow, on the other hand, always renders its own pages first — the API functions as a side channel, not the main way content reaches a reader.

Webflow's real API limits (and why they bite)

Nearly every comparison article mentions that "Webflow has limits," but very few of them list the actual figures, and almost none explain which specific limit is the one that causes real trouble once you're running this in production.

Rate limits, and the exception nobody mentions

According to Webflow's developer documentation, the Data API allows 60 requests per minute on the Starter and Basic plans, rising to 120 requests per minute on CMS, eCommerce, and Business plans. Enterprise customers negotiate a custom ceiling. Go over the limit and you get a 429 response back.

Here's the detail most write-ups leave out: requests to the Content Delivery API that come back from cache don't count toward that quota. Only calls that actually reach the Data API's origin server do. So if your integration is repeatedly reading published content without modifying anything, your practical rate limit is considerably higher than the published number implies. But if you're writing data, or reading uncached data, on every single call, that 120-requests-per-minute ceiling gets consumed quickly once you're synchronizing anything beyond a few hundred items.

Collection and field caps

On the CMS and Business plans, each collection is capped at 60 fields, and any multi-reference field can point to at most 1,000 items. Webflow's pricing update from May 2026 also introduced per-plan item ceilings: the CMS plan tops out at 2,000 collection items, Business can reach 20,000 with add-ons purchased, and Enterprise gets a negotiated custom limit. None of these thresholds cause trouble for a small marketing site with an attached blog. They start to matter once a product catalog or a documentation set grows past what your plan allows — the same goes for a content library that spans multiple locales.

One publish per minute

Per Webflow's own rate-limit documentation, site publish actions are restricted to one successful publish per minute. A CI pipeline configured to trigger a publish on every merge into main will start queuing behind that limit as soon as it sees real traffic, not merely as a hypothetical edge case.

Where a headless CMS API is a different shape entirely

A headless CMS is architected around its delivery API as the primary way content reaches consumers. There's no "cache versus origin" distinction to keep track of, because the delivery API is the only route content takes on its way to a reader. It's rate-limited and cached as a core design decision, not bolted onto a visual builder that was never meant to absorb that kind of traffic pattern.

The deeper structural difference is this: a headless CMS treats content modeling as its central interface, with any visual layer being optional or entirely separate from it. Webflow flips that priority — the visual builder is the primary interface, and the API is an accessory bolted on afterward. That difference in priority shows up clearly in what each product chooses to build first when adding new capabilities.

Where Webflow genuinely wins

It's worth being upfront about this. For a marketing team that wants exact visual polish without writing a line of code, Webflow's builder will beat what you'd get from Draftbase or any other headless option on that specific job. Pixel-level layout control through drag-and-drop simply isn't a battle headless platforms are trying to fight, and implying otherwise would mislead anyone weighing the two approaches against each other. When everyone touching the content is non-technical and the site is mostly static pages, Webflow's single-tool workflow is a genuine strength, not something you're settling for.

Where a headless CMS wins

Consider a case where the same content needs to feed a website, a mobile app, and some internal tool, all from a single schema. Under Webflow, that scenario runs straight into per-plan item ceilings and field caps, turning what should be routine work into a full migration effort. A headless CMS gives you typed fields and reference integrity from the start. Its delivery API is designed to handle thousands of calls a day without flinching. There's no artificial ceiling baked in. The API isn't an afterthought sized against what a visual builder's traffic patterns look like; it is the product itself.

When should you use Webflow instead of a headless CMS?

Reach for Webflow when the people editing content aren't developers, the site has a modest number of pages, and nothing beyond Webflow's own rendering needs to touch that content. Think of a restaurant's website, a single landing page for one product, or a small agency's portfolio. In these cases Webflow's visual editing wins on time-to-launch, no contest.

Can you combine Webflow with a headless CMS?

Yes, and by 2026 this pairing is fairly standard. Keep the marketing site on Webflow so you benefit from its design tools. Then pull out anything that functions as structured data, such as a product catalog, a documentation library, or user-generated content, and manage it through a separate headless CMS, rendering it on its own set of routes. That way non-technical staff still get Webflow's editor for the content they actually manage, while every part of the system where content volume or the number of consuming apps outgrows a coupled CMS gets a proper delivery API instead.

FAQ

Does Webflow count as a headless CMS? Not really. It exposes an API for reading data and writing to collections in a limited way, but at its core it's a coupled CMS designed first to render its own pages. A true headless CMS has no built-in rendering layer at all.

What rate limit applies to Webflow's API? According to Webflow's developer documentation, Starter and Basic plans get 60 requests per minute, CMS, eCommerce, and Business plans get 120, and Enterprise plans negotiate a custom limit. Notably, cached responses from the Content Delivery API don't count toward that quota.

What's the maximum number of items a Webflow collection can hold? 2,000 items on the CMS plan, rising to 20,000 on Business with paid add-ons, and a negotiable ceiling on Enterprise. These figures come from Webflow's pricing update in May 2026.

Is it possible to use Webflow's CMS as the backend for a completely separate application? In principle, yes, through its API. But you'll run into the item caps, field restrictions, and rate limits described earlier long before you would with a system built specifically for content delivery. Webflow's API exists to sync data into its own rendering pipeline, not to act as a general-purpose backend for outside applications.

The honest answer

Webflow and a headless CMS are built to solve different problems, not competing versions of the same one. The API constraints described throughout this article aren't a design flaw, they're the natural outcome of building an API around a visual builder rather than the reverse. If your team has no developers and the site comfortably fits within one plan's item cap, Webflow gets you there faster. If you're feeding more than one frontend from a single content model, Draftbase's headless CMS is built from the ground up to avoid that ceiling entirely. A companion piece walks through the implementation side of this decision in more depth. You can find it on HackMD: it covers fetching and caching content from a real delivery API using Node.js and Express.