How delivery works

Every event follows the same path: ingest, verify, persist, fan out, retry. Each step is observable in the console and through the API.

Ingest — the source sends an HTTPS request to the endpoint’s ingestion URL.
Verify — the provider adapter checks the signature, timestamp, and any source-specific rules.
Persist — the raw body, sanitized headers, and normalized event are stored before responding 202.
Fan out — the event is queued once per active destination.
Deliver — the target adapter sends the request and records the outcome; failures are retried with backoff.

Delivery guarantees

At-least-once delivery. A destination may receive the same event more than once, especially after a timeout. Deduplicate with X-Hooks-Delivery.
Ordering is not guaranteed. Each destination is retried independently. Use event timestamps if order matters to your system.
Paused endpoints stop new deliveries. Events still arrive and are stored, but fan-out waits until the endpoint is resumed.

Destination filters run at fan-out time. A rejected destination gets no delivery row, while the event stays stored for the audit trail.
Templates reshape the payload per delivery without a proxy.