POST request to your configured URL with the event details.
How webhooks work
- Register a webhook subscription specifying the table, events, and target URL
- Data changes — when a matching mutation occurs (via REST API or GraphQL), an event is published
- Delivery — the webhook service sends an HTTP
POSTto your URL with the event payload - Verification — validate the HMAC signature to ensure the request is authentic
Webhook management API
All webhook management endpoints are under/api/rest/_webhooks and require a management API token.
Required headers
Important: Theenvironmentheader is required for all webhook management endpoints. The header value must match theenvironmentfield in the request body when creating or updating webhooks.
Endpoints
Create a webhook
RequestRequest body
Optional filtering
Only fire the webhook when specific conditions are met:Field selection
Limit which fields are included in the event payload:List webhooks
Get webhook details
Returns the webhook subscription along with its recent delivery history.Update a webhook
Delete a webhook
Event payload
When a data mutation occurs, the webhook service delivers an HTTPPOST to your URL:
Note: ForDELETEevents,recordanddatacontain the record as it was before deletion. Thechanged_fieldsarray is empty forINSERTandDELETEevents.
Delivery headers
Each webhook delivery includes these headers:Verifying signatures
Every delivery is signed using HMAC-SHA256 with the webhook’ssecret. Always verify the signature before processing the payload.
Node.js example
Python example
Retry policy
If your endpoint returns a non-2xx response or is unreachable, the webhook service retries delivery with exponential backoff:
After the maximum retry attempts, the delivery is moved to a dead letter state and can be inspected via the webhook details endpoint.
Circuit breaker
If an endpoint fails consecutively, the webhook service activates a circuit breaker to protect your endpoint:- Opens after 5 consecutive failures per endpoint
- Cooldown period: 2 minutes
- During cooldown, deliveries are queued and retried after the cooldown expires
Best practices
- Always verify signatures — never trust a webhook payload without HMAC verification
- Respond quickly — return a
200status within 5 seconds; process events asynchronously if needed. Long-running handlers are the natural use case for custom functions — the webhook receiver dispatches to a function, which acknowledges immediately and processes in the background. - Handle duplicates — use the event
idto implement idempotent processing - Use HTTPS — webhook URLs must use HTTPS for secure delivery
- Monitor deliveries — check the webhook details endpoint regularly to catch persistent failures
FAQ
Where do I find webhook URLs to register with the third-party service?
Where do I find webhook URLs to register with the third-party service?
The integration’s settings page in your project shows the URL to register.
What is the timeout for handlers?
What is the timeout for handlers?
Return a
200 status within 5 seconds. Process longer work asynchronously and acknowledge the delivery first.Can I see a log of every webhook received?
Can I see a log of every webhook received?
Yes — the webhook details endpoint (
GET /api/rest/_webhooks/:id) returns recent deliveries with status, HTTP code, attempts, and timestamp.