Never lost, never fake
Events are queued in the same database write that caused them, and each delivery is signed so receivers know it's really you.
Wow your usersDeveloper platform
Outbound webhooks
Send events your customers can trust, and replay the ones that fail.
Tell your customers' systems when things happen in yours. Every event is signed, retried while their server is down, and logged so you can see exactly what was sent. When one fails for good, you replay it with a click.
HMAC-SHA256signature on every event sent8delivery tries before giving up30 daysof history you can replay
5 of 6 in Wow your users
Product example
See it working
This is the same visual component used by the authenticated app, rendered with deterministic sample data.
Scenario
viewport
surface theme
mode
Delivery history
Compare a successful signed delivery with a dead delivery that remains replayable.
Inert sample data · no network access
Preview ready
Highlights
Why it matters
Retries with patience
If a receiver is down, delivery retries up to 8 times with growing delays, then stops cleanly instead of looping forever.
A real answer to 'did it send?'
Every attempt is logged with its status and response. Admins can replay failed deliveries for 30 days.
The problem this solves
Without a shared foundation, every team rebuilds these edge cases — differently.
The event that never arrived
Your customer's server was down for a deploy. The webhook you sent inline with the request just died. No record, no retry, no way to resend. They find out a week later, from their own customer.
'How do we know it's really you?'
Your customer's security review asks how they verify your webhooks. Without signatures and timestamps, the honest answer is 'you can't.' That's a bad meeting. Signed events make it a short one.
Grepping logs for a maybe
A customer reports a missing event. Without attempt history, you're grepping logs and guessing. With it, you see the 503 on attempt three, and you hit replay.
How it works
The mechanism end to end, as implemented in the repository.
- 1
Events queue with the write
The event enters the queue in the same transaction as the change itself. If the change rolls back, no event. If it saves, the event can't be dropped.
- 2
A worker signs and sends
A background worker signs each delivery with the endpoint's secret and posts it with signature and timestamp headers, under a strict timeout.
- 3
Every attempt is recorded
Each try gets a durable attempt number and a logged result. Only server errors and timeouts retry; a hard failure like a 404 settles right away.
- 4
Dead letters wait for you
After 8 tries or 30 days, a delivery is marked dead instead of looping forever. Admins can replay it through the same worker, safely.
Engineering guarantees
What this does and does not promise
Safety boundary
Only event types that are actually built get advertised to your customers; draft definitions stay hidden. Delivery history shows status codes and short response snippets, never signing secrets.
Implementation evidence
The boundary above is code, not a claim. These files carry the contract:
src/registries/webhook-events.tssrc/features/developer-platform/delivery.tssrc/features/developer-platform/jobs.tssrc/features/developer-platform/crypto.server.ts
Questions
Frequently asked questions
Related capabilities
These capabilities share contracts and boundaries with this one.
Build on the outbound webhooks foundation
The docs describe the same contracts this page demonstrates.