Webhook
A webhook is an HTTP request the service makes to you when something happens, instead of you asking over and over whether anything has. You register a URL, choose the event types you care about, and answer quickly with a success status. Retries are the part that matters: an endpoint that is briefly down should not lose the events it missed.
At a glance
- Category
- Interfaces
- Direction
- The service calls you, not the other way round
- Configured by
- A URL plus the event types it subscribes to
- Expects
- A success status, quickly — do the work afterwards
- Retried
- On failure, with a growing delay
- Verified with
- A signature over the raw body and a timestamp
How it works
You register an endpoint and subscribe it to event types. When one occurs, the service posts a JSON body describing it, signed so you can tell it came from the service. Your handler answers with a success status as quickly as it can, and does the real work afterwards on a queue of your own. If your endpoint errors or times out, the delivery is retried with a growing delay for a bounded period, and every attempt is recorded so you can see what happened.
Why it matters
Polling for email events is both wasteful and late: most requests find nothing, and the ones that find something find it minutes after it happened. A webhook inverts that, so a bounce is in your database seconds after the receiving server refused the message. The design consequence is that your endpoint is now part of somebody else's critical path, which is why answering quickly and processing asynchronously is the difference between a resilient integration and an outage.
Example
An endpoint subscribes to delivery, bounce and complaint events. A message bounces permanently, and within seconds the endpoint receives a signed body naming the message, the address and the reply the receiving server gave. The handler verifies the signature, writes the event to a queue and answers with a success status in a few milliseconds. A worker then updates the customer record without holding the request open.
Common mistakes
- 01Doing the work inside the request, so a slow database turns into timeouts and then into retries of events you already have.
- 02Answering with a success status before verifying the signature, which means anything on the internet can write to your records.
- 03Assuming events arrive in order, when a retry can deliver an older event after a newer one.
- 04Treating a duplicate as an error rather than the expected consequence of at-least-once delivery.
In Rasket
Endpoints subscribe to the event types they want, every delivery records its attempts, and a failure is retried with a growing delay for about a day. Webhooks
Related terms
Frequently asked questions
What should my endpoint return?
A success status, as fast as possible, before doing any real work. Anything else is read as a failure and puts the delivery into the retry schedule.
Can the same event arrive twice?
Yes. Delivery is at least once, so a response that was sent but not received produces a retry. Make your handler idempotent by keying on the event identifier.
What happens if my endpoint is down for an hour?
Deliveries are retried with a growing delay for a bounded period, so a short outage loses nothing. A longer one may exhaust the schedule, which is why the delivery history is worth being able to replay.
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.