Polling vs webhooks, explained through an order update
Two systems need to agree that an order has shipped. One can ask for updates on a schedule; the other can send a notification when it changes. Here is what each approach asks of the software you build.
An API is an application programming interface, a defined way for programs to exchange information. Polling means calling an interface repeatedly to check for changes. A webhook delivers an event notification to an address registered by the receiving system. They can work together in the same integration.
Follow one order
Imagine an app showing the status of order 42. The order system knows whether it is packing or dispatched. The app needs an update when that status changes. The order number, paths and messages below are illustrative, not a real provider's schema.
- Polling. The app requests GET /orders/42 on a schedule. GET asks to read information. The order system returns the status at the time of each check. A change between checks waits until a later request is handled.
- Webhook. The app first registers an address and the event it needs. After dispatch, the order system sends a POST request to /hooks/orders. POST sends data to that address. The app replies to acknowledge receipt.
The example webhook message contains an event identifier, an event type and an order number. JSON is a structured text format often used for these fields. A provider may send a full record or only enough information for the receiver to fetch more detail.
The receiver has work to do
Validate the sender using the provider's documented signature checks. For our recommended flow, save the event durably, return a success response promptly, then do the longer work separately. A queue is a stored list of jobs waiting to run. An acknowledgement confirms receipt; it does not mean the dispatch email has already been sent.
Keep track of processed event identifiers and prevent a repeat delivery from repeating the business action. This is idempotency, meaning that processing the same operation again has the same effect as doing it once. For an order notification, that means avoiding duplicate emails even if the event arrives again.
Check the provider's delivery contract. Stripe documents automatic retries and warns that events can arrive out of order. GitHub requires you to arrange redelivery of failed webhook deliveries. Your recovery plan must match the service you connect to.
- GitHub webhook handling guidance
- Stripe event delivery and duplicate handling
- GitHub handling of failed deliveries
Choose around the update you need
Polling can be a reasonable choice when delayed updates are acceptable or the source offers no suitable event. Set the interval around that tolerance and the provider's request limits. Webhooks suit timely reactions to supported events, provided you can operate a receiver and recover failures.
For a broader guide to choosing and owning a business workflow, read Your business just got AI. Our automation service covers connecting the systems around that workflow.