Skip to main content
You don’t need this page to use Relay. It explains the guarantees on the other pages: why a 202 means your event is safe, why one slow endpoint doesn’t slow the rest, and where the delivery log comes from.
Architecture diagram: your app sends POST /v1/events to the Ingest API, which writes to a durable event log; the router matches events against endpoint subscriptions and puts one delivery per match on each endpoint's own queue; delivery workers sign and POST to your endpoints, send failed attempts to the retry scheduler, and write every attempt to the delivery log read by the dashboard and the CLI.

An event is written once to the event log, then becomes one delivery per subscribed endpoint, each with its own queue.

​
Ingest

The Ingest API checks your key, your rate limit and your idempotency key, then writes the event to the event log. It answers 202 only after the write is acknowledged, so an event you got a 202 for is not lost.

​
Event log

The event log is replicated across three availability zones and keeps events for 30 days. You can fetch any event in that window with GET /v1/events/{id}.

​
Routing

The router reads new events and matches each against your endpoints’ subscriptions. It creates one delivery per matching endpoint. A subscription change applies to events sent after it; events already routed keep their deliveries.

​
Delivery

Each endpoint has its own queue. Delivery workers take deliveries from each queue, up to the endpoint’s concurrency limit (10 by default), sign them and send them. A failed attempt goes to the retry scheduler, which puts it back on the same queue when its next attempt is due. Because queues are separate, an endpoint that times out on every request only delays its own deliveries.

​
Delivery log

Every attempt is recorded with its status code, response time and the first 4 KB of the response body. The dashboard and relay deliveries read from it. Attempts are kept for 30 days.