How to Set Up a Webflow Webhook That Fires When Your CMS Content Changes

How do I get notified the moment something changes in my Webflow CMS?

Register a webhook. Webflow sends a POST request to a URL you choose whenever the event you subscribed to happens, with a JSON body describing what occurred. No polling, no scheduled job asking whether anything changed, no delay between the change and your reaction.

This walkthrough is for someone who already runs a CMS-driven Webflow site and has started building automations around it. If you currently have a scheduled job that checks your own collection every fifteen minutes to see whether anything is new, this is the thing that replaces it.

I will cover what Webflow actually documents, which events are worth subscribing to, and the parts of building a receiver that people get wrong the first time.

What does a Webflow webhook actually send?

A POST request to your URL, with a JSON resource object relating to the event. Webflow's documentation describes the body as a JSON object containing a triggerType naming the event and a payload object carrying the details specific to that event.

The headers matter as much as the body. Webflow's docs say the request includes a Content-Type header set to application/json, an x-webflow-timestamp header with the time the webhook was sent, and an x-webflow-signature header containing the request signature. Webflow documents how to validate that signature.

That last header is the reason a webhook receiver is not simply an endpoint that accepts anything. Your URL is public, so anyone who discovers it can send it JSON. The signature is what lets your code tell a real Webflow event from someone else's POST.

Which events can you actually subscribe to?

Webflow's All Events reference documents a set of triggers covering CMS, site, page, form and comment activity. The CMS ones include collection_item_created, collection_item_changed, collection_item_deleted and collection_item_unpublished. Alongside those the reference also documents site_publish, page_created, page_metadata_updated, page_deleted, comment_created and form_submission, so most of what happens on a Webflow site can be reacted to.

Each event carries its own payload and its own required scope. Webflow's reference notes that form_submission requires the forms:read scope and site_publish requires sites:read, so the permissions you request when setting things up need to match the events you intend to subscribe to.

The site_publish payload is a good example of how much detail you get. Webflow documents it as carrying the siteId, a publishedOn timestamp as an ISO8601 string, the domains the site was published to, and a publishedBy object. That is enough to drive a real workflow without going back to the API for context.

Which event should you start with?

Start with the narrowest event that covers your actual need. If you want to react when a new post appears, collection_item_created is more precise than subscribing to every change. If you want to react when the live site itself updates, site_publish is the right level, and it will fire far less often than any of the item events.

The instinct is to subscribe to everything and filter in your own code. Resist it. Every event you accept is traffic you have to handle, log, and reason about, and a receiver that gets called on every field edit during an afternoon of copywriting will teach you that quickly.

The second consideration is timing. CMS item events describe changes to items, and site publish describes the site going live. Those are different moments, and if your automation cares about what a visitor can actually see, the publish event is the one that matches reality.

That distinction is also why a webhook pairs well with a deliberate release process rather than replacing one. If your changes currently go live the moment somebody saves, the gap worth closing first is a review step, which I set out in how to set up a staging workflow in Webflow.

How do you build a receiver you can trust?

Four properties, in this order: it validates the signature before doing anything else, it returns a success response quickly, it does the real work afterwards rather than during the request, and it can handle receiving the same event twice without doing the downstream work twice. Miss any one and it will bite you eventually.

Validating the signature comes first, before you parse anything or write anywhere. Treat an unsigned or badly signed request as hostile and discard it. This is the one step that turns a public URL into something you can safely connect to a system that matters.

Returning quickly is the second habit. A receiver that runs a three minute job before responding is a receiver that will eventually time out from the sender's point of view, and a sender that thinks delivery failed behaves differently from one that knows it succeeded. Accept the event, acknowledge it, then do the work.

Why does the same event sometimes arrive twice?

Because delivery over the internet is unreliable, and any sender that retries on failure will occasionally deliver something you have already received. Your receiver therefore has to be safe to call more than once with the same event, which is the property engineers call idempotency, and it is the single most useful habit here.

The practical implementation is to derive a stable key from the payload, usually the item identifier plus the event type plus the timestamp, and to record every key you have already processed. If a key arrives that you have seen, acknowledge it and stop. That single check removes an entire class of duplicate-record bug.

This matters more the further downstream your automation reaches. A duplicate notification in a chat channel is mildly annoying. A duplicate record in a CRM is a data problem somebody has to clean up, and I wrote about how to find that kind of drift in the daily reconciliation check I build for two connected systems.

What should you actually do when the webhook fires?

Something small and specific. The most useful first automation is a notification containing the item name and a link, so that somebody knows a thing happened. Get that working end to end before you attempt anything that writes data anywhere.

The reason to start small is that a webhook introduces a new failure surface, and you want that surface to be boring while you learn its behaviour. A notification that occasionally duplicates is a harmless way to discover that your receiver is not idempotent yet.

From there the useful patterns are narrow. Push a summary into a spreadsheet for reporting. Trigger a check that the new item has all required fields. Kick off a downstream job that regenerates something. Each of those is a single responsibility, which is what makes them debuggable when they fail.

When is a webhook the wrong tool?

When you need a guaranteed complete record rather than a timely notification. Webhooks tell you about events as they happen, and if your receiver is down for an hour, whatever happened in that hour may simply not reach you. A scheduled reconciliation against the API is what covers that gap.

The pattern I would recommend for anything important is both. Use the webhook for speed and use a periodic comparison for completeness. They fail in different ways, which is exactly why running both is more robust than running either alone.

Webhooks are also the wrong tool when the work you want to do is genuinely batch-shaped. If your process only makes sense over a day of changes, receiving fifty individual events and accumulating them yourself is more machinery than a scheduled job that reads the collection once.

Where does this fit with the rest of an automation stack?

It is the trigger layer. The webhook tells you something happened; everything interesting is what you connect it to, whether that is a CRM, a spreadsheet, a chat channel, or your own code. The same principles apply regardless of what sits downstream.

If you already connect Webflow to other tools through a form integration, this is the CMS equivalent of that habit, and the same care about field mapping applies. I walked through the form side of this in connecting a Webflow contact form to HubSpot through Zapier.

If the downstream work is content operations rather than data movement, a webhook is a natural trigger for a scripted job rather than a no-code workflow, and I set out how I structure that kind of pipeline in automating Webflow content updates with the Claude Code SDK.

What should you do next?

Pick the one event you actually care about, point a webhook at a throwaway receiver, and look at the payload it sends. Do that before you design anything, because the real payload will shape the design more accurately than any plan will.

Once you have the payload, write the signature check and the duplicate check before you write the useful part. Those two pieces are the difference between an automation you trust and one you have to babysit.

If you are trying to decide whether a webhook or a scheduled job is the right fit for something you are building, tell me what has to happen and how quickly. I will tell you which one I would use. Let's chat.