Webflow Webhooks: Send Form and Publish Events to Sazabi

Webhook facts checked on the platform’s docs on Nov 8, 2026.

A Webflow webhook tells another system when something happens on a site: someone submits a form, you publish, a CMS item changes, an order comes in. This page covers what Webflow sends and how to keep those events in Sazabi.

What Webflow sends

Each webhook listens to one trigger type. The documented types include form_submission, site_publish, page_created, page_metadata_updated, page_deleted, ecomm_new_order, ecomm_order_changed, ecomm_inventory_changed, collection_item_created, collection_item_changed, collection_item_deleted, collection_item_published, collection_item_unpublished and comment_created.

The request is a POST with a JSON body in two parts. triggerType names the event, and payload holds the event data. Unlike platforms that put the event name in a header, Webflow puts it in the body, so one Sazabi URL can take several trigger types and you can still tell them apart.

Why send it to Sazabi

Form submissions and publishes are the moments a marketing site changes in ways that matter to engineers. A broken form, a publish that landed just before a traffic dip or a flood of submissions all show up as events. Sazabi's Webhook Events source stores each JSON payload as a searchable log record, with the data under webhook.* attributes, next to your other logs.

A path suffix such as /webflow is stored as webhook.path. If you want one stream per site, include the site in the suffix, for example /webflow/marketing-site.

Set it up in Webflow

1. Open Site settings, then Apps and integrations, then Webhooks.
2. Select Add webhook.
3. Choose a trigger type, such as Form submission or Site publish.
4. Choose the API version, v1 or v2.
5. Paste your Sazabi intake URL with a suffix as the webhook URL.
6. Save, then trigger the event: submit the form or publish the site.

Repeat for each trigger type. Webflow allows up to 75 webhooks for a single trigger type. The form submission trigger also accepts a filter with a form name when you create it through the API, which helps if one site has many forms.

Example payload

An abbreviated form submission using the field names in the Webflow docs. It is an example, not a captured delivery.

{
  "triggerType": "form_submission",
  "payload": {
    "name": "Contact Us",
    "siteId": "65427cf400e02b306eaa049c",
    "data": { "First Name": "Zaphod", "email": "zaphod@heartofgold.ai" },
    "submittedAt": "2024-07-30T20:07:15.220Z",
    "id": "66a947f35b9d7ba400e22733",
    "formId": "65429eadebe8a9f3a30f62d7"
  }
}

In a Sazabi thread, search for a top-level field such as webhook.triggerType to isolate one kind of event.

Submitted form data lands in Sazabi as written, so a contact form with email addresses or phone numbers stores those values. Decide whether that fits before you point a form at it.

What to watch for

• Strict success rule. Webflow counts anything other than a valid HTTP 200 as a failure. Redirects, certificate problems and timeouts count too. After your first test, check that Sazabi doesn't hold repeated records for the same submission id, which would mean Webflow saw failures and retried.
• Deactivation. If Webflow keeps hitting failures it deactivates the webhook and emails you. Recovery goes through Webflow support, so catch a failing webhook early.
• Duplicates. After retries one event can arrive more than once. The payload id is the identifier to compare.
• Gaps after a deactivation. Quiet form events during a busy week are a reason to check the webhook before the form.
• Publish noise. site_publish events include a publishScope of site or page, so a page-level publish can look like a full release unless you read it.

The Intake page in the Sazabi dashboard shows ingestion volume per source, which makes a drop easy to spot.

Retries

Webflow expects a 200 response. Otherwise it retries up to three more times, at an interval of ten minutes, and then stops. Its limits table lists 75 webhooks per trigger type and three retry attempts. Webflow also signs requests with x-webflow-signature when you create webhooks through the API, but not for dashboard webhooks. Webflow signs a timestamp, a colon and the body.

Teams that run forms elsewhere can send Typeform responses the same way, and store events can come from Shopify.