Why We Do Not Sync Your Webflow CMS in Real Time

Should your Webflow CMS sync in real time?

Almost never, and the platform itself explains why. Webflow limits site publishing to one successful publish per minute. A sync that writes a CMS item and publishes on every change is competing with that limit from the first hour, and the failure is silent enough that nobody notices for weeks.

This comes up on most integration projects. A client has product data in Airtable, or job listings in a recruiting tool, or case studies in Notion, and the brief says the website should update instantly. It is a reasonable thing to want.

It is also the wrong shape for how Webflow works, and choosing a slower design on purpose produces a more reliable site. Here is our reasoning and the published numbers behind it.

What are the actual limits?

Webflow publishes them plainly. The Data API allows 60 requests per minute on Starter and Basic plans, 120 on CMS, eCommerce and Business plans, and a custom limit on Enterprise.

Exceed it and the API returns an HTTP 429 Too Many Requests error with a Retry-After header telling you how long to wait, which Webflow says is typically 60 seconds. Three response headers let you watch the budget: X-RateLimit-Limit for the overall per-minute limit, X-RateLimit-Remaining for what is left this minute, and Retry-After when you have run out.

Sixty requests a minute sounds generous. It is, for reads. It stops being generous the moment a sync updates a hundred items in one run, because each item is at least one request and often two.

Why does the publish limit matter more than the request limit?

Because writing a CMS item is not the same as showing it. Webflow states that "Site Publish operations are limited to one successful publish per minute", and publishing is what makes a change visible on the live site.

So a real-time design runs into a hard ceiling that has nothing to do with how fast your integration is. You can write ten items in two seconds. You cannot publish ten times in ten seconds. The changes queue behind a limit you do not control.

That is the number we bring into the first conversation, because it reframes the question. The debate is not how quickly we can push data. It is how often the site can reasonably be republished.

What does "real time" usually mean when a client asks for it?

Within a few minutes, almost always. When we ask what event they are imagining, the answer is usually a colleague updating a price or adding a job listing and wanting to check it on the site before the meeting.

That is a five minute requirement described with a one second word. Nobody in these conversations has ever needed sub-second propagation of a case study.

The exceptions are real but narrow: live inventory counts, event capacity, anything where showing stale data costs money. Those deserve a different architecture, which we get to below.

What do we build instead?

A batched sync on a fixed interval. The integration collects every change since the last run, writes them to the CMS in one pass, and triggers exactly one publish at the end.

That shape respects both limits by design. One publish per run means the publish ceiling is never in play. Writing in one pass means you can pace requests against the per-minute budget and read the remaining count from the response headers rather than guessing.

It also makes failures legible. One run either succeeded or did not. Compare that with a hundred independent triggers where three failed at 4am and you find out when a client asks why a page is wrong. We covered the general build in syncing Airtable and Notion to the Webflow CMS.

When should you use webhooks?

For the direction that actually benefits from being immediate: Webflow telling you something happened. Webflow's webhook triggers include form_submission, site_publish, page_created, page_metadata_updated, page_deleted, collection_item_created, collection_item_changed, collection_item_deleted, collection_item_unpublished, comment_created, and the ecommerce events ecomm_new_order, ecomm_order_changed and ecomm_inventory_changed.

A form submission reaching your CRM in two seconds is genuinely valuable. Nobody is waiting on the page to repaint, so the publish limit never enters the picture.

The asymmetry is the useful insight. Outbound events from Webflow should be event-driven. Inbound content into Webflow should be batched. Most integrations we inherit have this exactly backwards. The wider tradeoff sits in webhooks against polling in automations.

What breaks when you ignore the limits?

Partial updates, which are worse than no update. A sync that writes forty of sixty items and then starts collecting 429 responses leaves the site in a state that matches neither the old data nor the new.

The second failure is retry storms. An integration that treats a 429 as a generic error and retries immediately makes the situation worse, because it spends the next minute's budget before the minute arrives. Webflow hands you the Retry-After value precisely so you do not have to guess, and ignoring it is the most common bug we find.

The third is invisibility. Most no-code automation platforms mark a run as failed and move on. Unless someone built an alert, a broken nightly sync is discovered by a customer. Every sync we build reports its own success or failure somewhere a human will see.

Does the CDN cache change the maths?

For reads, yes, and it is worth knowing. Webflow notes that cached requests to the content delivery API have effectively no rate limits, while uncached requests that reach the origin count against your plan limit.

That matters if you are reading Webflow content into another system, such as a mobile app or a search index. Pulling from a cached path is far cheaper than hammering the origin.

It changes nothing about writes or publishes. Caching is a read-side benefit, and the ceiling we design around is on the write side.

How do you decide the batch interval?

By asking what the slowest acceptable answer is, then doubling the safety margin. Our defaults are fifteen minutes for content that changes through the day, hourly for reference data such as integrations or locations, and nightly for anything sourced from a system that updates in batches anyway.

Then we add one manual trigger. A button, a form, or a command that someone can run when they need the site updated now. That single addition removes most of the pressure behind the original real-time request, because the real requirement was usually control rather than speed.

For very large collections there is a further constraint on how much you can move in one window, and that changes the interval too. We wrote about the shape of that in working with large Webflow CMS collections.

Where does real time genuinely belong?

Outside the CMS. If a number must be current to the second, render it in the browser from an API call rather than storing it as CMS content and republishing the site. Live inventory, seats remaining, a status indicator: those belong in a fetch, not in a publish.

That split keeps each system doing what it is good at. Webflow holds content that a person edits and a page renders. A client-side call holds the one value that changes faster than a page can be rebuilt. Trying to make the CMS behave like a live database is the decision that creates the problem.

If you have an integration that publishes on every change and you are wondering why the site is occasionally wrong, that is usually the cause and it is usually a half day to fix. Tell us about it at phoenix.studio.