Webflow CMS Sync Limits: What Breaks When Both Sides Write

Webflow's published request caps are rarely what breaks a Webflow CMS sync. The limits that take a running integration down are state and delivery rules, and there are six of them: items created through the staged endpoints are always drafts, the isDraft flag does not unpublish anything, archiving waits for a full-site publish, a failed webhook stops retrying after three further attempts, dashboard-created webhooks arrive unsigned, and Webflow's event list never says which actor changed an item, so a two-way job has to assume it is hearing its own writes. In the syncs I build for agencies, those six rules cause more incidents than every rate cap combined.

• API writes land as drafts. Webflow's reference says of the staged item endpoints: "Creating a new item with these endpoints always creates a draft." (Webflow Data API reference)
• isDraft is not an unpublish switch. "Setting isDraft: true doesn't unpublish an item." (Webflow publishing docs)
• Archiving is deferred. "Archiving unpublishes items from your live site at the next full-site publish." (Webflow publishing docs)
• Webhook delivery is best effort. A non-200 response means "the webhook will be retried up to three more times", at a documented interval of 10 minutes. (Working with webhooks)
• Dashboard webhooks cannot be verified. Webflow states that "webhooks created through the dashboard will not include the request headers needed to validate request signatures." (Working with webhooks)
• Your own writes come back as events. Webflow lists collection_item_changed among its webhook events without distinguishing which actor changed the item, so a two-way job has to recognise the echo of its own write. (Working with webhooks)

Webflow publishes the numeric caps that people usually mean by sync limits, and sizing for them is the easy half of the job: requests per minute per API key, items per bulk request, CSV file size, and the collection and item ceilings on each plan. I set those out with their sources in connecting the Webflow CMS to Airtable, Notion and Google Sheets, and collection architecture decides how much of any of this you have to handle at all, which is the subject of Webflow CMS structure. Where a sync tool belongs in the wider toolset sits in the Webflow tech stack guide. A sync that respects every published cap can still publish nothing, hide nothing, and report no error, and that is what the rest of this post is about.

Why does a two-way Webflow CMS sync loop?

A two-way Webflow CMS sync loops when a write made by your own job produces a change event, your receiver treats the event as news from the other side and writes back, and the write produces another event. Webflow publishes collection_item_created, collection_item_changed, collection_item_deleted, collection_item_published and collection_item_unpublished as event types without stating which actor the change came from (Working with webhooks), so a two-way job cannot assume an incoming event represents a human edit. On the projects I lead, the job is built to recognise its own echo before it is allowed to write in both directions.

• Keep a short-lived record of what you wrote. Hold each item id you just wrote for a few minutes and drop the matching inbound event, which is the cheapest guard and needs nothing from the payload.
• Compare timestamps instead of trusting direction. The created-item payload documents createdOn, lastUpdated and lastPublished (collection item created reference), so a receiver can ignore an event whose lastUpdated matches the write it just made.
• Decide whose edit wins, in writing. Neither platform decides that for you, so the sync has to carry the rule: last write wins, source system always wins, or Webflow wins for a named list of fields.
• Verify the echo on the client's own site. Webflow's documentation does not promise that API writes are excluded from webhook delivery, so I treat the echo as present until a test on that site shows otherwise.

Decision rule: if you cannot name the loop guard and the conflict rule in one sentence each, the integration is not ready to write in both directions.

Why does a synced Webflow CMS item never appear on the live site?

A synced Webflow CMS item does not appear on the live site because the staged endpoints create drafts by default, and a draft needs a separate publish step. Webflow's own reference is explicit about the two endpoint families: the staged endpoints "Manage staged items on a site" and "Creating a new item with these endpoints always creates a draft", while the live endpoints "only work for live items" (Webflow Data API reference). Webflow describes staged content as "Draft content that can be previewed but isn't visible on the live site" and live content as "Content that's published and visible on your site" (publishing docs). A CSV import can leave items as drafts too, for a different documented reason that I cover in the Airtable, Notion and Google Sheets post, so check which path created the item before debugging the wrong one. The rule I apply on client projects is that no sync job is finished until it has read the item back and confirmed a non-null lastPublished.

• Write to a staged endpoint, then publish the item, or wait for a site publish, which picks the item up only while isDraft is false: Webflow notes that staged content "will be published on the next site-wide publish".
• Publishing a single item lets you "Publish, unpublish, or stage a single item without affecting other content", which is the safer option while a client has unrelated work staged in the Designer.
• A full-site publish will "Publish all staged content across your entire site in a single operation", including anything else sitting staged.
• Scheduled publishing is not a sync tool: Webflow states plainly that scheduled content "can not be controlled by the CMS API".

What does isDraft do to a live Webflow item?

Setting isDraft to true on a live Webflow item marks that item's changes as staged while the item itself stays published, so it does not take anything off the live site. Webflow's publishing documentation says "When a live item's isDraft property is set to true, it remains published on your site", that "The changes will only go live when the item's isDraft property is set to false and the item is published again", and flatly that "Setting isDraft: true doesn't unpublish an item" (Webflow publishing docs). What I see teams get wrong here is treating the flag as a visibility toggle inherited from their source system, where hiding a record hides it everywhere.

• To take an item off the live site, call the unpublish operation, which "doesn't delete the item from the CMS" and instead "unpublishes it and sets its isDraft property to true".
• To remove an item from the live site on the next publish, archive it: archiving "unpublishes items from your live site at the next full-site publish" but "keeps the items accessible in the CMS".
• A live item can carry a staged version at the same time, since "A live item can have a staged version for updates that don't affect the original".
• If a record disappears from the source system, the sync needs an explicit unpublish or delete path, because no flag change on its own removes the public page.

Decision rule: if your source system has a boolean for visibility, map it to Webflow's unpublish and publish operations, never to isDraft alone.

What happens when a Webflow webhook fails?

When a Webflow webhook fails, Webflow retries it up to three more times at a documented interval of 10 minutes and then stops, and the lost event produces no error anywhere in the Webflow interface and none in your source system either (Working with webhooks). When I audit an integration for this, the first thing I check is whether anything other than the webhook itself would notice a missed event.

• Your endpoint should return 200: "Your service should return a 200 response to show that the webhook was successfully captured."
• Anything else triggers limited retries: "If the response status is anything else, the webhook will be retried up to three more times", with the limits table giving 10 minutes as the "Interval (in minutes) between each retry".
• Three retries at 10-minute intervals gives about 30 minutes of delivery coverage, which is my arithmetic from the retry count and interval Webflow publishes rather than a figure Webflow states.
• Slowness counts as failure: "Webflow expects a swift response during webhook delivery", and "If there are prolonged delays in receiving a response from your server, it will be considered a failure."

Decision rule: if a missed event would leave the live site wrong for more than an hour, add a scheduled reconciliation pass and stop treating webhooks as the system of record.

How do you verify a Webflow webhook is genuine?

A Webflow webhook is verified by hashing the request against the two headers Webflow sends with every API-created webhook: an x-webflow-signature "formatted as a SHA-256 HMAC hash" and an x-webflow-timestamp holding "The time the webhook was sent, represented in Unix epoch time format", with Webflow advising that "If the difference exceeds 5 minutes (300,000 milliseconds), consider the request potentially compromised" (Working with webhooks). The catch is where the webhook came from: Webflow states that "webhooks created through the dashboard will not include the request headers needed to validate request signatures", so a receiver fed by a dashboard subscription has nothing to check. When I set up a sync, every subscription is created through the API for that reason alone.

• Create subscriptions through the API, not the dashboard, or the signature headers never arrive.
• Reject a request whose timestamp is more than 5 minutes old, which is the replay window Webflow names.
• Read the payload against the reference table, not the sample: Webflow's collection_item_created reference documents the booleans as isDraft and isArchived, while the sample payload on the same page shows draft and archived, so a receiver coded from the sample can read a key the table does not list (collection item created reference). I handle both spellings and log which one arrived.
• Treat an unsigned payload as untrusted input and reconcile it against a read from the API before writing anything back.

Which Webflow CMS sync limits break a live site?

The six Webflow CMS sync limits that break a live site rather than a request are draft on create, isDraft treated as a hide switch, deferred archiving, dropped webhooks, unverifiable dashboard webhooks, and the two-way echo loop. Each one is worth naming in writing before any integration is built, because every one of them produces a wrong public page with no error message. Each row below pairs the documented Webflow behaviour with the consequence a client actually sees and the first thing to check.

Failure mode	What Webflow does	What the client sees	First check
Silent draft	Staged create "always creates a draft"	Record exists in the CMS, missing from the live site	Read the item back and look for a null lastPublished
Draft flag as hide switch	"Setting isDraft: true doesn't unpublish an item"	Content the source system marked hidden is still public	Compare the source visibility flag against the live page
Archive lag	Archiving unpublishes "at the next full-site publish"	A deleted record stays live for hours or days	Confirm a site publish ran after the archive batch
Dropped webhook	Retries stop after "three more times" at 10-minute intervals	One record silently stale with no error anywhere	Diff the source record count against the collection
Unverifiable webhook	Dashboard webhooks arrive without signature headers	No way to tell a real event from a forged POST	Check whether the webhook was created via the API
Echo loop	Change events carry no indication of which actor wrote	Fields flipping back and forth, or a runaway write loop	Trace one field through a full round trip in a staging collection

Webflow's limits table also caps the "Maximum webhooks for a specific trigger_type" at 75 (Working with webhooks), which starts to matter once several apps subscribe to the same CMS event on one site. App permissions decide how much damage any of these can do, since a sync app that holds write scope on pages and publishing can change more than a collection. I broke down what the Marketplace listings actually request in the write permissions Webflow apps ask for, and the same reasoning belongs in the stack choices covered in the Webflow tech stack guide.

Can a Webflow CMS collection safely sync in both directions?

A Webflow CMS collection can safely sync in both directions when one system is the declared source of truth, the job recognises its own echo, deletions have a real path to the live site, and a scheduled pass reconciles whatever the webhooks miss. On the projects I lead, the default is one-way out of the system of record, with Webflow treated as a presentation layer, and two-way writes are earned rather than assumed. The scorer below is the six-question version of the conversation I have with an agency before signing off on a two-way setup.

Want your Webflow sync reviewed before it writes to a live collection?

Bring the collection schema and the sync job, and in 15 minutes I will tell you which of the six failure modes above your setup is exposed to, whether your deletion path actually removes the public page, and what a reconciliation pass would need to check. You can book a 15 minute Webflow sync review and leave with that list whether or not we work together.