Article sections
Polling or webhook? Choose based on event frequency, acceptable delay, and ERP support.
An ERP system needs to know when a new order comes in, when stock changes, or when a price updates. You can get that information in two ways: polling or webhook. The wrong choice wastes resources or delays the data. The two approaches differ in delay, resource use, and ERP support.
Quick definitions
Polling means your system regularly asks the ERP: “Anything new?” It asks at a fixed interval, say every 5 minutes. The ERP answers every time, even if nothing changed. It is easy to set up, but it uses resources even when nothing happens.
Webhook means the ERP itself notifies you when a change occurs. You give it an address (a URL), and it sends an HTTP message when a change happens. Efficient, but it requires the ERP to support this feature and you need to handle errors more carefully. When you set up a webhook, your system exposes an HTTP endpoint that the ERP calls automatically on each event. You must validate the request’s signature and reply with a 200 status code; otherwise, the ERP retries a few times with increasing intervals.
Decision table
| Criterion | Polling | Webhook |
|---|---|---|
| Initial complexity | Low. A cron job or a simple loop. | Medium. You need to set up the endpoint, validate requests, and manage retries. |
| Resource efficiency | Low. You send requests even when nothing happens. | High. Resources are used only on events. |
| Lag | Depends on the interval. At 5 minutes, max delay is 5 minutes. | Depends on the network, the source system, and the request path. |
| Reliability | Predictable. If a request fails, the next one comes at the set interval. | Fragile. If a notification is lost or the endpoint is down, the event may be missed. Requires retries and idempotency. |
| Needs ERP support | No. Any ERP with an API can be polled. | Yes. The ERP must have a webhook mechanism configured. |
| Best fit | Rare, predictable events (e.g., price update once a day). | Frequent or urgent events (e.g., live orders in a restaurant). |
When to choose polling
If events are rare and you don’t need an immediate reaction, polling is enough. A store that updates prices once a day can poll every hour or even every 30 minutes. The max delay is 30 minutes. Whether that’s acceptable depends on the cost of the delay. If an old price stays up for 30 minutes, are you losing money? Then polling is not okay.
Polling is also the safe choice when the ERP doesn’t support webhooks. In that case, it’s your only option. You set up a job that runs at an interval, checks a last-modified date or a flag, and pulls what changed. Your polling job runs every 5 minutes, sends a request to the ERP API with a last-modified parameter, gets a response with all new or modified records, then processes them and updates the local database.
When to choose webhook
A webhook is right when time matters. A restaurant chain may receive orders continuously. A 5-minute delay means lost orders or wrong stock counts. In this case, a webhook is the only option.
But it adds complexity. The ERP must send the notification. You need an endpoint to receive it. If the endpoint is down, the ERP will retry a few times. If those retries fail, the event is lost. You need to implement a fallback: a backup polling once an hour, to catch missed events. When your endpoint goes down, the ERP tries retries with exponential backoff multiple times. If all fail, you lose the event for good unless you implement a backup polling that checks periodically and recovers the data.
Simple decision rule
- Rare, predictable events → polling.
- Frequent, urgent events → webhook.
Decide based on event frequency and the delay you can accept.
What if you’re not sure?
You can start with polling. It’s easy to set up and change later. Measure how many requests you send and how many are empty. If most requests bring nothing new, switch to webhook. Or combine them: poll at a wide interval for slow updates, use webhook for fast ones. Measure for a week how many empty requests your system sends and how many real events occur. Then calculate the percentage of useless requests and decide if switching to webhook cuts bandwidth and processing costs. If that percentage goes high enough, the effort is worth it.
Watch out for pitfalls
Webhooks require idempotency. The same event might be sent twice. Your system must ignore duplicates. Without that, an order could be processed twice. Idempotency means your system stores a unique ID for each received event, checks if it already processed it, and if so, ignores the duplicate and replies with a success code so the ERP doesn’t retry.
Polling requires backpressure. If the ERP responds with many orders in a single request, your system must process them all before the next interval. Otherwise, they pile up.
How to decide
Choosing between polling and webhook is a practical architecture decision. Pick polling when events are rare and webhook when delay is critical. Use measurements to confirm your choice. Measure event frequency, resource costs, and delay tolerance for a week. Compare useless requests to missed events. Keep the mechanism that meets your store’s operational thresholds.