Configuration

Open an endpoint in Settings → Webhooks to view and change its configuration.

Verifier schemes

The verifier decides how incoming requests are authenticated. Which schemes are available depends on the endpoint's target:

  • Channel post endpoints use one generic scheme — Shared secret (header token). Channel posts are for tools that can only send a static header (PostHog, Datadog, Grafana), so there's no scheme to choose.
  • Workflow trigger endpoints verify a real provider's event signature, so they expose the full set of signing schemes below. Pick the one that matches whoever signs the events.
SchemeHeaderSignsUse for
TAP v1 (HMAC-SHA256)TAP-SignatureHMAC-SHA256("<t>." + body) + timestamp, replay-tolerantDefault; first-party senders
Generic HMAC-SHA256X-SignatureHMAC-SHA256(body)Custom senders with a shared secret
GitHub SHA-256GitHub's headerGitHub's signature schemeGitHub webhooks
Stripe v1Stripe's headerStripe's signature schemeStripe webhooks
Svix / Standard WebhooksSvix headersthe Standard Webhooks signatureSvix and Standard-Webhooks senders
Shared secret (header token)Authorization: Bearer … (or X-Webhook-Secret)nothing — the endpoint secret is presented as a static tokenSenders that can't HMAC-sign (PostHog, Datadog, Grafana, Zapier/Make)

For the provider schemes, configure the provider's webhook with the endpoint URL and its signing secret — the provider signs each request, and the platform verifies it. Only requests that verify against the endpoint's secret are accepted.

Shared secret (header token) is for senders that can only send a static header, not a signature. Configure the sender to send the endpoint secret as Authorization: Bearer <secret> (or X-Webhook-Secret: <secret>); it's compared in constant time. Note this is weaker than the signed schemes — it authenticates the sender but gives no per-request body integrity or replay protection (a captured request can be replayed until you rotate the secret), so it relies on TLS. Rotate the secret like any other. See connecting no-signature tools.

Response mode

Controls what the sender receives back:

  • On received (202 immediately) — acknowledge as soon as the event is verified and accepted. Default, and the right choice for fire-and-forget senders and channel posts.
  • Last node output — for workflow triggers, respond with the last node's output once the run finishes.
  • Custom response node — for workflow triggers, respond with the output of a designated response node.

A response timeout bounds how long the sender waits for last_node / response_node responses.

Signing and replay tolerance

  • Signature tolerance — for timestamped schemes (TAP v1), how far the request timestamp may drift from server time before it's rejected as a replay. Keep it tight; widen only if senders have significant clock skew.
  • Body size limit — requests larger than this are rejected before processing.

Rotating the secret

Use Rotate on the endpoint's signing secret to issue a new whsec_… value. Rotation supports an overlap window: the previous secret keeps verifying until it expires, so you can roll the new secret out to the sender without dropping in-flight deliveries. The endpoint shows whether an overlap is active and when the previous secret expires. Once the sender is updated, let the old secret lapse.

Identity

A channel-post webhook posts as a system author using the endpoint's display name, so messages read as coming from the integration (e.g. "Deploys") rather than a raw id. The author is shown with a webhook glyph icon.

Status

An endpoint can be disabled (manually or automatically) or revoked. A disabled or revoked endpoint rejects incoming events; re-enable or recreate it to resume delivery.