When two systems need to stay in sync, someone has to initiate the exchange: the external system can notify us through webhooks, or our system can check for changes through polling. Both strategies work and have advantages, but either can become a problem when chosen out of habit. It doesn't matter which one looks more modern. What matters is which one fits the kind of data you're moving.
This decision is often part of a broader set of API integration services, where you also need to define which system is authoritative and how failures are recovered.
What a webhook does
A webhook lets one system notify another when something happens. An order was created. A customer changed. A payment was completed.
A product was updated. Instead of constantly checking whether something changed, we wait for the source system to send a notification. That can make syncing almost instant and avoids a lot of unnecessary requests. In the ideal case, the flow is simple: something happens → the webhook arrives → we process the change. The problem is the ideal case isn't always the real one.
What polling does
With polling, we do the opposite. Our system periodically asks the other one: "Is there anything new?" It could be every minute.
The interval might be one minute, five minutes, or an hour, depending on how long the information can wait. A basic implementation queries records modified since the last sync and processes only those changes.
It's less immediate than a webhook, but it has an important advantage:
we're the ones controlling when the sync happens.
Real time doesn't always mean better
Suppose we are syncing prices between two systems. Whether a three-minute delay affects the business depends on how those prices are used; the architecture alone cannot answer that question.
If nothing important changes, a periodic sync can be a lot simpler to operate than an event-based infrastructure. Now think about a payment. When the provider confirms a transaction was approved, we probably want to process that information as soon as possible.
That's where a webhook makes a lot more sense. The speed you need should come from the problem. Not from the architecture.
Webhooks can get lost
A webhook is an HTTP request. And HTTP requests can fail. Our server can be down. It can respond too slowly.
There can be a temporary network issue. The provider can have an outage. That's why a serious integration shouldn't assume every webhook will arrive exactly once. Some services retry automatically.
Others make a few attempts. Others don't guarantee much at all. You need to know how the provider you're working with actually behaves.
They can also arrive twice
This is pretty normal. The service sends a webhook. We process it correctly. But our response takes longer than expected.
The provider assumes something went wrong and sends it again. If our code just runs the operation again, we can duplicate orders, payments, emails, records, or internal processes. That is why a webhook should be processable idempotently. Idempotency, ordering, and retries also belong to the broader design of an API integration beyond the happy path.
If the same event arrives twice, the result should be the same as if it had arrived once.
And they can arrive out of order
Imagine these events:
- Order created
- Order paid
- Order canceled
We shouldn't assume they'll necessarily arrive in that order. Due to latency, retries, or the provider's internal processing, we might receive the third one first and the second one after. If we apply each event blindly, we can end up rebuilding a state that never existed.
Sometimes it's better to use the webhook purely as a heads-up:
something changed.
And then query the current object directly from the API. That adds a request, but it can significantly simplify state handling.
Polling is simple, but it can get expensive
Querying an API every minute sounds simple. The approach becomes harder with a hundred thousand products, rate limits, several clients, and many concurrent sync processes. If every run downloads everything just to find five changes, you're doing a lot of unnecessary work. Polling works better when the API lets you ask for incremental changes.
For example:
Useful mechanisms include updated_since, cursors, modification dates, ordered pages, and incrementing identifiers. The idea is to only query what might have changed.
Frequency needs a reason
It's common to find processes running every minute simply because someone picked that interval when building them. But the sync interval should balance how long the business can wait against how much each run costs.
A store's inventory might need to update pretty frequently. A catalog that changes once a week probably doesn't. An integration doesn't get better by running more often. It gets better when the data arrives within the time it's still useful.
Sometimes it's worth using both
Webhooks and polling aren't necessarily mutually exclusive. A fairly robust strategy can use webhooks to react quickly and polling as a reconciliation mechanism. The webhook notifies us almost in real time. Every so often, we also check whether there's a change that, for some reason, didn't arrive.
That lets you take advantage of event speed without fully trusting that no notification will ever get lost. For important data, it can be worth it.
You have to think about the external system going down
With polling, if the external API doesn't respond, we can log the error and try again later. With webhooks, another question shows up. What happens if our system is down for twenty minutes? Does the provider store the events?
Does it resend them? For how long? Is there an API we can use to recover what happened during that period? If we don't know how to answer that, we have a hole in the integration.
The architecture should account for how to recover state after an outage.
Security changes too
A polling process normally starts the connection from our system toward an authenticated API. A webhook does the opposite. We're exposing an endpoint for another system to call us. That means we need to verify the request actually comes from the expected provider.
Many services sign their webhooks with a shared secret. Our endpoint can validate that signature before processing the content. It's not enough for someone to just know the URL. A webhook is an entry point into the system and should be treated as one.
Don't process everything inside the webhook
Another useful decision is to respond fast. When a webhook arrives, we can validate the request, store the event, and return a successful response. The heavy lifting can run afterward through a queue or a background process. That reduces the risk of the provider interpreting the request as failed because we took too long.
It also provides better control over retries and load. The webhook communicates the event and the system processes it, but those tasks do not need to happen in the same request.
What to choose
If the change needs to show up quickly and the provider has a reliable webhook system, that's probably where I'd start. If a few minutes of delay are acceptable and the API lets you query changes efficiently, polling can be a lot simpler.
If the data is critical, it might make sense to combine both. And if we still don't know how much latency matters, we probably don't need to start with the more complex option.
The architecture has to follow the data
Webhooks and polling are mechanisms. They aren't product decisions on their own. The real question is: what happens if this data takes five minutes? what happens if we lose an event? can we rebuild the state? how much volume are we going to process? who controls the external system?
With those answers, the choice usually becomes a lot less mysterious. The choice narrows once we know the tolerable latency, query cost, and recovery path. Not everything needs real time; each piece of data needs to arrive within its useful window.