Use a webhook. A webhook is Webflow calling you instead of you asking Webflow. When someone submits a form, publishes the site, or edits a CMS item, Webflow sends a message to a web address you choose, within seconds, without anyone checking anything.
Most teams do the opposite by accident. They set a tool to check Webflow every fifteen minutes for changes. That wastes requests, adds delay, and still misses things. A webhook flips the direction and removes both problems.
The concept sounds technical and mostly is not. If you have ever set up a Zapier automation that starts when a Webflow form is submitted, you have already used a webhook without calling it one.
It is a registration that says "when this event happens on my site, send the details to this URL." Webflow stores the pairing. When the event fires, Webflow sends an HTTP POST request carrying JSON describing what happened. Your endpoint receives it and does whatever you want.
The three moving parts are the trigger, the destination, and the payload. The trigger is the event type you care about. The destination is your URL. The payload is the data Webflow sends, which varies by event.
Nothing about this is Webflow specific in concept. Stripe, GitHub, and Slack all work the same way. Learning webhooks once means you can wire almost any two modern tools together.
What makes them powerful is immediacy. A webhook turns your website from something you check into something that tells you. That is the difference between finding a lead the next morning and calling them back in five minutes.
Thirteen, grouped into five families. Webflow's developer documentation names them all. There are form, publishing, page, CMS, ecommerce, and comment events, and you register separately for each type you want.
The one most businesses start with is form_submission, which fires when a form is submitted on the site. Alongside it sits site_publish, which fires when a site is published to its domains, and comment_created, which Webflow describes as firing on "a new comment or a reply to an existing thread" in the Designer.
Page events cover the structure of the site. Webflow provides page_created when a new page is added, page_metadata_updated which fires when "metadata of page is updated and published", and page_deleted when a page is removed. These are how you keep an external record of what pages exist, which matters more than it sounds on large sites.
CMS events are the richest group. Webflow offers collection_item_created, collection_item_changed, collection_item_deleted, and collection_item_unpublished. Between them you can mirror every content change into another system as it happens.
Ecommerce sites get three more. Webflow documents ecomm_new_order for a customer placing an order, ecomm_order_changed when an order's status or details are modified, and ecomm_inventory_changed for inventory quantity or type changes.
Either through the site settings interface or through the API. To do it programmatically, Webflow documents a POST request to https://api.webflow.com/v2/sites/{site_id}/webhooks using a bearer token, and notes that the call requires the sites:write scope and returns a 201 status code on success.
Only two fields are required. Webflow lists triggerType, the event you want to listen for, and url, the endpoint that should receive the data. That is the whole minimum configuration, which is why webhooks are quicker to set up than most integrations.
There is one optional field worth knowing about. Webflow documents a filter parameter and states it is "only supported for the form_submission trigger type." So you can narrow form webhooks to particular forms, but you cannot filter the other event types at registration. Filtering for those has to happen in your own code after the message arrives.
The successful response includes the webhook ID, workspace ID, site ID, and a creation timestamp. Store that webhook ID somewhere. You will need it to delete or audit the registration later, and hunting for it afterwards is tedious. The same token rules apply here as everywhere else in the platform, which we cover in our guide to the Webflow Data API.
Yes, and it is generous. Webflow's documentation states a "limit of 75 registrations per triggerType, per site." So a single site can have up to seventy five separate form submission webhooks, seventy five site publish webhooks, and so on for each of the thirteen types.
In practice nobody reaches that ceiling by design. Teams reach it by accident, because every experiment leaves a registration behind and nobody cleans up. We have seen sites with dozens of live webhooks pointing at endpoints that stopped existing years ago.
Stale webhooks are not harmless. They fire on every matching event, fail, and make it much harder to tell whether your one real integration is working. Auditing the list once a quarter takes minutes.
The healthier pattern is one endpoint per event type that routes internally. Rather than registering five form webhooks pointing at five tools, register one pointing at your own service, and let that service decide who needs to know. It is easier to change and far easier to debug.
Polling asks repeatedly. A webhook tells you once. Polling means calling the API on a schedule to check whether anything changed, which costs requests whether or not there is news. A webhook costs nothing until something actually happens.
The cost difference is real because Webflow's Data API is rate limited. Its documentation sets the limit at 60 requests per minute on Starter and Basic plans, and 120 requests per minute on CMS, eCommerce, and Business plans. A polling loop spends that budget on empty checks. Webhooks leave it available for the work that matters.
Latency is the other difference. Polling every five minutes means an average delay of two and a half minutes before you know about a new lead. A webhook is typically seconds. For sales enquiries that gap changes outcomes.
Polling still wins in one case. If your endpoint cannot be publicly reachable, or you need a guaranteed complete picture rather than an event stream, a scheduled sync is simpler and more predictable. Many mature setups use both, with webhooks for speed and a nightly sync as a safety net.
To something that is always available and answers quickly. That can be an automation platform such as Zapier or Make, a serverless function on Vercel or Cloudflare Workers, or your own server endpoint. What it cannot be is a laptop, a staging URL, or anything that sleeps.
Answer fast and do the work later. The right shape for a webhook endpoint is to accept the request, acknowledge it immediately, and queue the real processing separately. Endpoints that call three slow APIs before responding are the ones that time out and lose messages.
For teams without developers, an automation platform is the sensible destination. It gives you retries, logging, and a visible history of every message, which is worth a great deal when something goes wrong at 2am. We compare those platforms in our guide to automating web workflows with Zapier and Make.
Whatever you choose, log the raw payload somewhere before you process it. When an integration misbehaves, the first question is always what Webflow actually sent, and without a log you are guessing.
Treat the endpoint as public, because it is. Anyone who learns the URL can send it fake data. So the endpoint must verify that a message is genuine before acting on it, and it must never do anything destructive based on an unverified request.
Use HTTPS, use an unguessable URL path, and check the payload's shape and contents before trusting it. If a webhook triggers something consequential, such as sending money or emailing customers, add a second confirmation against the API rather than acting on the message alone.
Check Webflow's current webhook documentation for signature verification details before you build, rather than assuming a particular header exists. Verification mechanisms change, and the documentation is the only reliable statement of what is available today.
Finally, remember that form submission payloads contain whatever your visitors typed, which often means names, emails, and phone numbers. That data is now flowing through every system in the chain, so each one needs to be somewhere you are comfortable storing personal information. We touch on the form side of this in our guide to building Webflow forms that capture more leads.
When you need certainty rather than speed. A webhook is a message that might not arrive. Networks fail, endpoints go down, and a missed message is simply gone unless something is designed to notice. If a process must never miss an item, pair the webhook with a reconciliation job that checks for gaps.
They are also wrong when the receiving system cannot keep up. A bulk CMS import can fire hundreds of item events in a burst. If your endpoint processes each one slowly and synchronously, you will build a backlog and probably drop messages. Queue first, process second.
And they are unnecessary when nothing downstream cares. Registering a webhook for every event because you can is how sites end up with the stale registration problem above. Add one when a specific system genuinely needs to know something specific.
Our rule is that a webhook should always have a named job and a named owner. If nobody can say what breaks when it stops working, it should not exist.
Pick the one event where minutes matter to your business. For most companies that is a form submission. Register a single webhook for it, point it at a place that logs everything, and watch a few real submissions arrive. Once you trust the data, wire it into the tool your team actually works in.
Then go and audit whatever webhooks already exist on your site. On any site more than a year old, expect to find registrations nobody remembers creating, and delete the ones pointing nowhere.
If you want help designing an integration that stays reliable rather than one that works on the day it is built, we are happy to walk through it with you. Reach out through phoenix.studio and tell us what needs to know when your site changes.
Tell us where you want to go. We'll tell you how we'd get you there.