Webhook

webhook · web hook · http callback · reverse api · push notification endpoint · callback url

Definition

A webhook is a push-notification mechanism over HTTP: when an event occurs, the source service immediately sends a request to a URL the recipient has registered, with no periodic polling required.

How a webhook works

A webhook inverts the usual request–response pattern: instead of the recipient asking the source,
the source notifies the recipient.

An event at the source (a new order)
        ↓
POST https://receiver.example/webhooks/orders
Content-Type: application/json
X-Signature: sha256=abc123...

{
  "event": "order.created",
  "order_id": "12345",
  "user_id": "u_789",
  "total": 49.90,
  "timestamp": "2025-03-15T14:30:00Z"
}
        ↓
Recipient → HTTP 200 OK → processing on a queue

The recipient has to return 200 quickly, without blocking on business logic. Heavy processing goes
onto an asynchronous queue.

Webhooks against polling

Property	Webhook	Polling
Delay	Milliseconds	Up to one polling interval
Load on the source	Minimal	N requests a second regardless of events
Work for the recipient	A public endpoint	A scheduler plus the request
Reliability	Needs retry logic	Easier to guarantee

For real-time events — order sync, price updates, user actions — webhooks are preferable. Polling is
justified when the source does not support webhooks, or when events need to be aggregated in
batches.

Reliability and idempotency

A webhook endpoint has to be idempotent: the same event can be delivered twice, for example on a
retry after a timeout. Processing logic must not create duplicate records on a repeat delivery.

The standard defence against duplicates is to store processed event IDs in a cache such as Redis or
Memcached, with a TTL equal to the source’s maximum retry window.

Important: verify the HMAC signature before you process the request body. It is the only
reliable way to know the webhook came from a trusted source rather than from an unrelated request
to your public URL.

Webhooks in e-commerce integrations

In e-commerce, webhooks are used most often for:

Catalogue sync: the personalization platform is notified about price and stock changes from
the ERP or PIM immediately
Order events: the payment system notifies the CRM and the CDP about a new order so the
customer profile can be updated
Behavioural events: the mobile app sends events into the personalization platform so the
affinity profile stays current in real time

Frequently asked questions

How does a webhook differ from polling?

With polling the recipient periodically asks the source whether there is anything new. That creates unnecessary load and adds a delay of up to one polling interval. A webhook inverts the pattern: the source notifies the recipient at the moment of the event. For real-time events such as a new order or a price change, a webhook is an order of magnitude more efficient.

How do you make webhooks reliable?

The recipient should answer HTTP 200 as fast as possible without blocking on processing. Heavy logic belongs in an asynchronous queue. The source should implement retries with exponential backoff on errors. The recipient must be idempotent, because the same event can be delivered twice.

How do you secure a webhook endpoint?

The standard approach is an HMAC signature: the source signs the request body with a secret key and passes the signature in a header such as X-Signature. The recipient verifies the signature before processing. On top of that: IP allowlisting and an idempotency check on the event ID.

Which e-commerce events usually travel over webhooks?

Order creation and updates, delivery status changes, stock and price updates, new user registration, profile changes and cart events for real-time personalization. Anything another system needs to react to immediately.