Outbound event delivery
EventRelay sits between your app and every customer webhook endpoint — signing, guarding, retrying, and logging each delivery so a flaky third-party server never becomes your on-call problem.
self-hosted · Postgres + Redis · no vendor lock-in
What actually happens to your event
Not a black box — three things every webhook system should show you, and usually doesn't.
Destinations are re-validated against a private-IP and metadata-endpoint blocklist before the first request and again before every redirect it follows.
Every payload carries an HMAC signature your receiver can verify. Send the same idempotency key twice and get the same event back, not a duplicate.
Every event and every attempt against it, searchable — status, response code, and how many times it's been retried.
| Type | Status |
|---|---|
| order.created | delivered |
| invoice.paid | delivered |
| user.updated | failed |
When the other side breaks, not you
Customer webhook servers time out, redeploy, and rate-limit you at the worst moment. EventRelay assumes that's normal and plans around it.
After three exponential-backoff attempts, a delivery moves to dead-letter and alerts you — resend it the moment the endpoint's back.
Each key gets its own rolling per-minute limit and a visible prefix, so you can revoke one without rotating them all.
A signing secret is shown once, at creation. The database only ever holds an encrypted copy — there's nothing for a dump to expose.
whsec_3f8a1c…e02bAn idempotency key on the request means retries from your side never fan out twice.
DNS-resolve the destination and reject anything private, loopback, or link-local.
HMAC-sign the payload and POST it, following redirects one re-validated hop at a time.
Exponential backoff for three attempts, then a logged dead-letter with a manual resend.
curl -X POST /events -H "X-API-Key: er_live_…" -d '{"type":"order.created","data":{...}}'