Webhook endpoints
Create webhook endpoints and inspect their lifecycle delivery health.
Webhooks creates and manages the organisation's endpoints for lifecycle events. The platform delivers every event the organisation's endpoints receive under a retry and signature contract. It retries eligible failures with exponential backoff and jitter for up to three days from event creation. HTTP 408, 429, 5xx responses, and connection failures can retry; other 4xx responses stop delivery. It also signs every delivery so the consumer can verify it came from the platform.
Retryable failures use exponential backoff with jitter. Terminal failures stop immediately. A receipt-enabled endpoint also needs a valid countersigned receipt before delivery is complete.
Configure an endpoint when another system needs notifications about the organisation's platform events.
Creating an endpoint, changing its subscriptions, or rotating its signing secret is one of the operations the organisation's Audit trail records, alongside your name and role at the time. Audit trail does not cover individual delivery attempts; use this endpoint's own Deliveries tab for those.
The decision that matters most when creating an endpoint is which events to subscribe to, not the URL itself. Subscribing broadly means the consumer sees everything and can filter locally, at the cost of processing deliveries it may never act on. Subscribing narrowly cuts noise, but means a new event type the consumer later needs requires you to come back and add it. Whichever you choose, the consumer's own reliability matters more than the subscription list. Automatic retries stop when the event's three-day window closes. After a longer outage, inspect the delivery history and use the Platform API's webhook replay operation for supported retained events. Reconcile any remaining gap against current platform state.
Steps
Open Webhooks
Open Organisation settings, then Webhooks. Endpoints belong to the active organisation, so confirm you are in the right one before creating or reviewing one.
Screen equivalent: the page summarizes recent delivery health and lists configured endpoints.
Create an endpoint
Select Create endpoint, enter the consumer URL and subscriptions, then create it. Copy the dalp_whsk_ signing secret from the reveal dialog before closing it because the Console does not show it again; your consumer needs it to verify the signature on every delivery.
Review deliveries
Open an endpoint. Use Overview for recent lifecycle health, Deliveries for attempts and test events, and Settings for endpoint and secret controls.
Troubleshooting
The signing secret was not saved
Rotate the signing secret from Settings. Save the newly revealed value before closing the dialog.
A rotated secret breaks signature verification
Rotation keeps the previous secret active alongside the new one for 24 hours, so a consumer verifying against the old secret still accepts deliveries during that window. Update the consumer to the new secret before the 24 hours close.
An event never arrived and deliveries have stopped
Check the delivery age against the three-day retry window. Once an event passes that window, or once a delivery fails in a way the platform treats as non-retryable, the platform stops automatic attempts. Inspect the last failure and use a supported replay after fixing the consumer.
Deciding how broadly to subscribe an endpoint
A broad subscription is simplest to set up, and never needs revisiting when the organisation adds a new event type the consumer should already know about. It sends every event to a consumer that may only care about a handful of them, so plan for the consumer to filter on its side. A narrow subscription keeps delivery volume down, but means updating the endpoint's subscriptions whenever the consumer's needs grow. Treat a narrow subscription as something to revisit alongside changes on the consumer side, not a one-time setup step.
An endpoint was down for an extended period
If the outage lasted less than three days, the backed-up deliveries resume retrying on their existing schedule once
the endpoint comes back, so check Deliveries for a wave of attempts succeeding in sequence rather than assuming they
are lost. If the outage exceeded three days, any event whose retry window closed during the outage has stopped
retrying automatically. Request a supported replay for retained events through the Platform API, and reconcile any
remaining gap against current platform state.