# What is Webhook Delivery?

Also called webhook, event callback.

Webhook delivery is the mechanism by which one system notifies another of an event by sending an HTTP request to a receiver supplied URL. It replaces polling with push, so the receiver learns about changes promptly. Reliable delivery requires signature verification, retries with backoff, duplicate tolerance on the receiving side, and a record of attempts that can be inspected and replayed.

The sender's responsibilities are dispatch and persistence. It records that an event occurred, attempts an HTTP request to the configured endpoint, treats a success status as delivered, and schedules a retry otherwise. Retries use increasing delays over a bounded window, after which the event is marked failed. Senders commonly disable endpoints that fail continuously and notify the owner rather than retrying forever.

The receiver's responsibilities begin with verification. Because the endpoint is publicly reachable, anyone can post to it, so payloads are typically signed with a shared secret and a timestamp. The receiver recomputes the signature, rejects mismatches, and rejects timestamps outside a short window to limit replay. Treating an unverified webhook body as trusted input is a well known and serious vulnerability.

Receivers must also expect duplicates and disorder. Retries after an ambiguous timeout mean the same event can arrive more than once, so handlers should be idempotent keyed on the event identifier. Events can arrive out of order or reflect state that has since changed, which is why many receivers treat the webhook as a signal to fetch current state rather than as authoritative content.

The most common operational mistake is doing real work inside the request handler. Senders enforce short timeouts, so a handler that processes the event synchronously will time out under load, causing retries that add still more load. The durable pattern is to verify the signature, persist the payload, acknowledge quickly, and process asynchronously from a queue.

## Key points

- Push notification over HTTP replacing receiver side polling.
- Verify the signature and timestamp before trusting any payload.
- Retries with backoff mean duplicates are expected.
- Acknowledge fast and process asynchronously from a queue.
- Keep an inspectable attempt log so events can be replayed.

## In practice

A payment provider sends a webhook when a subscription renews. The receiving endpoint verifies the signature against a shared secret, rejects the request if the timestamp is more than five minutes old, writes the raw payload to a table keyed on the provider's event id, and returns success in under one hundred milliseconds. A worker then picks up the stored event, and because the key already exists it ignores a duplicate delivery that arrives moments later.

## Related terms

- [Idempotency](/en/glossary/idempotency)
- [Retry policy](/en/glossary/retry-policy)
- [Exponential backoff](/en/glossary/exponential-backoff)
- [Dead Letter Queue](/en/glossary/dead-letter-queue)
- [Queue](/en/glossary/queue)

[Back to the AI Glossary](/en/glossary)