Relay Webhook Delivery

What it does

Relay accepts synthetic events, creates an HMAC using SHA 256, and delivers each request to a registered demo endpoint. It has an ASP.NET Core API, a separate .NET worker, a PostgreSQL database, a Next.js dashboard, and a receiver simulator. Docker Compose starts the five services together.

Delivery path

The API validates and stores each event before the worker claims queued deliveries from PostgreSQL. Claims use FOR UPDATE SKIP LOCKED, so several worker instances can take different jobs without processing the same delivery at the same time. The dashboard shows endpoint state, delivery history, attempts, correlation IDs, and errors.

Failure and duplicate handling

Failed requests are retried after one, two, and four seconds, with a maximum of four attempts. Expired worker claims are recovered after a crash. Idempotency keys protect event creation and manual replay from duplicate requests, while replay creates a new delivery linked to the failed original.

Verification

The repository has 26 unit tests, 35 PostgreSQL integration tests, 15 frontend tests, and four Playwright workflows. CI builds all five Compose services and exercises successful delivery, retry exhaustion, replay, endpoint lifecycle, filtering, pagination, and history retention.

Why the retry delays are short

Relay waits one second before the first retry, two before the next, and four before the last. These delays keep the full failure path practical to test on a laptop. Relay is a local demo, not a hosted service.

Relay accepts only the demo destinations listed in the repository. It has no authentication, multitenancy, billing, cloud setup, or support for arbitrary URLs. Before it could accept real destinations, it would need destination ownership checks and authentication.