Polling vs Webhooks
A comparison of pull-based polling and push-based webhooks for asynchronous result delivery.
Jul 11, 2026
Polling and webhooks are delivery mechanisms for retrieving the result of an Asynchronous Request-Response operation. Neither removes the need to persist job state, authenticate requests, handle duplicates, or define expiry.
| Concern | Polling | Webhooks |
|---|---|---|
| Direction | Requester pulls status | Provider pushes an event |
| Receiver availability | Requester chooses when to query | Callback endpoint must be reachable |
| Completion latency | Bounded by polling schedule | Usually close to event delivery time |
| Load | Repeated status reads | Delivery attempts and retries |
| Recovery | Query the durable operation state again | Retry delivery or reconcile later |
| Security | Authenticate status reads | Authenticate callback origin and payload |
| Duplicates | Repeated reads are normal | Duplicate delivery must be expected |
Polling
The provider returns an operation ID and exposes a status resource. Polling works well when request volume is modest, completion time is unpredictable, clients cannot accept inbound traffic, or the current state must remain queryable after completion.
Use exponential backoff with jitter, respect server retry hints, and stop at a documented deadline. A constant short interval can create synchronized load even when few operations change state.
Long polling can reduce empty responses by keeping a status request open until the state changes or a timeout expires.
Webhooks
A webhook sends an authenticated HTTP request to a callback endpoint when state changes. The sender should sign the payload, include a timestamp and delivery ID, retry transient failures with backoff, and retain an observable delivery history.
The receiver should verify the signature against the raw request body, reject stale timestamps, deduplicate delivery IDs, and acknowledge only after the event is durably recorded. Source IP allowlists can supplement authentication but are not sufficient on their own.
Webhooks should usually notify the receiver that state changed rather than act as the only copy of the result. The receiver can fetch the authoritative operation resource when payload size, privacy, or recovery requirements make that safer.
Choosing
Choose polling when inbound connectivity is difficult or consumers need control over read timing. Choose webhooks when low notification latency matters and both sides can operate authenticated retries. High-scale systems often provide both: webhooks for prompt notification and polling for reconciliation.