Webhook Fundamentals
Webhooks vs Polling
When systems need to exchange updates, developers usually choose between polling an API repeatedly or receiving event notifications through webhooks. Both approaches solve the same problem but behave very differently in production.
Polling and webhooks represent two different communication models between systems.
Polling means the client repeatedly checks whether something has changed. Webhooks reverse the flow: the server sends a request when an event occurs.
Understanding the trade-offs between these approaches helps engineers design more reliable integrations.
How polling works
Polling requires the client to repeatedly ask the server for updates.
GET /api/payments/status
If nothing changed, the server returns the same response again. The client continues sending requests until the desired change appears.
Polling is easy to implement but can generate unnecessary traffic when updates are infrequent.
How webhooks work
Webhooks invert the communication model. Instead of asking repeatedly, the receiving system exposes an endpoint that the provider calls when events occur.
POST /webhooks/payment
This allows systems to react to events immediately without sending constant requests.
Latency comparison
Polling latency depends entirely on the polling interval.
If a client polls every 60 seconds, the worst-case delay before detecting an update is also 60 seconds.
Webhooks deliver events almost immediately after they occur, making them better suited for real-time workflows such as payment confirmations or deployment notifications.
Infrastructure cost
Polling generates continuous API traffic even when nothing changes.
At scale this can produce significant infrastructure overhead because every client keeps requesting updates.
Webhooks reduce unnecessary traffic because events are delivered only when something happens.
Reliability trade-offs
Polling is predictable because the client controls request timing.
Webhooks introduce more moving parts such as retries, signature verification, and endpoint availability.
For this reason, webhook handlers must handle duplicate events and retries safely.
See our guide on why webhook providers cannot guarantee delivery.
The hybrid architecture most systems use
Many production systems combine both approaches.
Webhooks provide real-time notifications, while polling serves as a fallback to verify system state.
For example, a SaaS billing system may process Stripe webhook events for subscription updates while periodically polling the API to confirm subscription status.
This hybrid strategy protects against rare cases where webhook events are delayed or lost.
When to use polling
- when updates occur very frequently
- when real-time updates are not critical
- when external callback endpoints are not possible
When to use webhooks
- event-driven systems
- payment notifications
- automation workflows
- deployment pipelines
Key takeaways
- Polling repeatedly checks for changes.
- Webhooks push events when they occur.
- Polling is simpler but less efficient.
- Webhooks reduce traffic and enable real-time updates.
- Many production systems combine both approaches.