Gateways and delivery

A gateway forwards the events of one source to one endpoint of yours. Creating one is covered step by step in create a gateway; this page is the reference for what each setting does.

Destination settings

Setting	Where	Notes
Name	Dashboard, API	Shown in the event log, the DLQ and alerts.
URL	Dashboard, API	Absolute http/https. Public hosts only.
Response timeout	Dashboard (seconds), API (timeout_ms)	Default 10 s. Range 1–300 s.
Authentication	Dashboard, API (auth_config)	None, HMAC signature, API key or basic auth.
Retry schedule	API (retry_policy)	Default 30s, 2m, 10m, 1h, 4h.
Fixed headers	API (custom_headers)	Sent verbatim on every delivery.
Status	Dashboard, API	active or paused.

How a delivery works

1. An accepted event is queued for every enabled gateway on its source.
2. A connection filter that does not match records the delivery as filtered; nothing is sent.
3. Otherwise the transformation is applied, then the authentication headers.
4. Webhooker POSTs the payload and waits up to the timeout.
5. The response decides the outcome: 2xx succeeds, a 4xx other than 408 and 429 fails permanently, everything else is retried on the schedule.

Deliveries are independent. Three gateways on one source means three deliveries, three attempt histories and three retry schedules — one dead endpoint never delays the others.

Delivery is at-least-once. A response that never reaches Webhooker — a timeout after your handler already committed — is retried, so your handler should be idempotent. Use the event id from X-Webhooker-Event-Id, which stays the same across every attempt and every replay of that event.

Ordering

Events are not delivered in a guaranteed order. Retries mean a webhook that arrived first can land second, and independent deliveries run in parallel. If order matters, sort on a field inside the payload — providers almost always include a sequence number or a timestamp — rather than on arrival order.

Fan-out

One source, several gateways: send payments to your API, a filtered subset to a Slack relay, and everything to an archiver. Each gateway has its own filter, transformation, secret, timeout and history.

One destination, several sources: reuse an endpoint with Connect existing when you add it to another source. Its settings, circuit state and retry schedule are shared; the filter and transformation belong to each connection separately.

Pausing and disabling

• Disable a connection (the toggle on the row) — events are stored and not forwarded to that one gateway.
• Pause a destination — no deliveries to that endpoint from any source.
• Pause a source — events accepted, no deliveries at all.

None of the three loses events: they stay in the log and can be replayed once you re-enable.

Private and internal endpoints

A destination URL must resolve to a public address. localhost, *.local, *.internal and private IP ranges are rejected when you save, and hostnames that resolve to a private address are blocked at delivery time. For local development use the CLI, which pulls events to your machine instead of having them pushed.