# Gateways and delivery

How a destination is configured, how delivery works, and what fan-out to several endpoints does.

Source: https://docs.webhooker.eu/deliver/gateways/

A gateway forwards the events of one source to one endpoint of yours. Creating
one is covered step by step in [create a gateway](/guides/create-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 `POST`s 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](/tutorials/local-development/), which pulls events to
your machine instead of having them pushed.