Skip to main content
A webhook channel POSTs platform events to any HTTPS endpoint you control. Each channel picks its own event types, deliveries are signed, and failures retry automatically with exponential backoff for about 33 hours before slipway gives up and disables the endpoint. Discord and Slack channels receive platform-native messages instead of this schema, but share the same event selection and retry pipeline.

Request

Every delivery is an HTTPS POST with these headers: Your endpoint must respond with a 2xx status within 15 seconds. Anything else, including a timeout, counts as a failed attempt and is retried.

Body

The four original kinds (deployment.healthy, deployment.updated, deployment.failed, and deployment.torn_down) additionally carry the legacy top-level keys (event, ts, organization, repository, deployment) exactly as the original payload documented them, so receivers written before per-event selection keep parsing without changes. Treat those keys as deprecated and read data instead.

Verifying signatures

Set a signing secret on the channel and every delivery carries:
The digest is HMAC-SHA256 over the concatenation of the event id, the timestamp, and the raw request body, joined with .:
Binding the id and timestamp into the MAC protects you against replay: reject deliveries whose timestamp is older than your tolerance (5 minutes is typical) and deduplicate on the webhook id. Verify in constant time before trusting anything in the payload.
The legacy X-Slipway-Signature: sha256=<hex> header (HMAC-SHA256 over the raw body alone) is still sent for backwards compatibility, so existing receivers keep working. New receivers should verify the v1 scheme.

Retries

A failed attempt (non-2xx, timeout, or connection error) is retried on this schedule, with a little jitter: The final attempt lands roughly 33 hours after the event. If all 8 attempts fail, the delivery is marked exhausted and the channel is automatically disabled: nothing else is delivered to it until someone re-enables it. When that happens, slipway notifies your org’s admins in the in-app inbox and posts a notice to your remaining channels, with a link to the channel’s settings page. Because retries and redeliveries reuse the event id, design your receiver to be idempotent: process each X-Slipway-Webhook-Id at most once.

Delivery history and redelivery

Every channel’s page in the console (Settings → Notifications → the channel → Deliveries) lists recent deliveries with their status, attempt count, and last HTTP response code. Click a row to inspect the exact payload and the last error, and use Redeliver to queue a fresh copy of any event. It keeps the original event id, so an idempotent receiver will recognise the duplicate. History is retained for 30 days.

Choosing events

Each channel subscribes to any combination of event types; the full catalog with descriptions is in the webhook events reference. By default a channel receives events from every project in the organization; to narrow it, open a project’s Settings → Notifications and toggle the channel on there, which scopes it to just the projects you’ve toggled. Organization-level events (members, billing, domains) ignore project scoping.