Webhooks or Scheduled Sync?
By CodexierPublished 6 min read
Every integration between two systems has to answer one question: how does system B find out that something changed in system A? Either A pushes a message the moment it happens, which is a webhook, or B asks on a schedule, which is a scheduled sync or polling. Both work. They fail differently, cost differently and suit different data. This guide explains the mechanics in plain terms and gives a rule for choosing per flow.
What webhooks and scheduled syncs are
| Aspect | Webhook (push) | Scheduled sync (pull) |
|---|---|---|
| Latency | Seconds | The schedule interval: minutes to a day |
| Who initiates | The source system | Your job |
| If your side is down | Events are lost unless the source retries | The next run picks up everything |
| Load pattern | Spiky, follows activity | Predictable, at the times you choose |
| Needs a public endpoint | Yes, with authentication | No |
| Ordering and duplicates | Must handle out-of-order and repeated deliveries | Naturally idempotent if written well |
Speed vs reliability
The appeal of webhooks is immediacy: an order in the shop appears in the CRM before the customer has closed the tab. The cost is that each event is delivered once, to an endpoint that must be up, must respond quickly and must cope with the same event arriving twice or two events arriving in the wrong order. A scheduled sync gives up immediacy and in return gains a property that matters more than most people expect: it converges. Whatever went wrong last night, tonight's run asks for everything since the last successful checkpoint and repairs the gap.
- Ask how stale the data may be before someone notices or is harmed. If the honest answer is hours, a sync is enough.
- Ask what happens if one event is missed. If a missed event means a customer is never invoiced, you need reconciliation regardless of the mechanism.
- Ask who is watching. A webhook that silently stops needs monitoring on the receiving side; a sync that fails at night needs an alert in the morning.
Failure handling and retries
Integrations are judged by how they fail, not how they run on a good day. Both approaches need a plan for errors, but the plans look different.
Webhook: acknowledge fast, process later
Store the incoming event and respond immediately, then process from the queue. A slow endpoint gets timed out and the source may stop sending.
Webhook: expect duplicates
Most sources retry on failure, so the same event can arrive twice. Store the event id and ignore repeats; make every update safe to apply twice.
Sync: checkpoint by time or cursor
Record the last successfully processed timestamp or cursor, and always overlap a little on the next run. Missing a window is worse than reprocessing one.
Both: reconcile
A daily or weekly job that compares counts and totals between the two systems catches whatever both mechanisms missed. Our Fortnox integration guide shows why this matters for money.
Costs and limits
Webhooks are cheap per event but need infrastructure that is always on: a public endpoint, a queue, monitoring and someone to fix it when the source changes its payload format. Scheduled syncs consume API calls in bursts, which runs into rate limits on systems like Fortnox, HubSpot or Shopify if the interval is too short or the data set too large. Automation platforms bill per operation, so a sync that checks every minute can cost far more than a webhook that fires only when something happens.
- Check the source system's rate limits and whether it offers a changed-since filter; without one, polling has to fetch everything every time.
- Check whether the source offers webhooks at all and whether it retries; some retry for days, some not at all.
- Price the automation platform per run if you use one; per-minute polling adds up.
- Budget developer time for change: webhook payloads and API versions change, and the integration needs an owner.
Choosing per data flow
Do not choose for the whole project; choose per flow. New lead from the website to the CRM: webhook, because response time wins deals. Orders from the shop to accounting: nightly sync with reconciliation, because correctness beats speed and the accountant works in the morning anyway. Stock levels to a marketplace: webhook for sales plus an hourly sync to catch drift. Customer records between two systems: scheduled, in one direction, with a defined master. Where you need both speed and certainty, run the webhook for the fast path and a scheduled sync as the safety net. This is the kind of design we do in our integration and automation optimisation work, often on integrations that already exist but keep drifting.
When you do not need either: if two systems exchange a handful of records a week, a manual export and import, or a native connector with its own schedule, is cheaper than building and owning an integration. When the flow is real, and especially if it moves money or leads, the choice above is worth an hour of thought. If you would like that hour compressed into fifteen minutes with someone who has built both, book a free call and bring the list of systems and what needs to move between them.
Frequently asked questions
Are webhooks more secure than polling?
Neither is inherently more secure. Webhooks require a public endpoint, which must verify a signature or secret on every delivery and reject anything else. Polling keeps the endpoint private but stores an API key that must be protected. Both need the same care with credentials.
How often should a scheduled sync run?
As rarely as the data allows. Nightly is right for accounting, hourly for stock and reporting, every few minutes for operational data where a delay is visible to customers. Shorter intervals cost API calls and platform operations without adding value if nobody acts on the data faster.
Can we use both on the same data?
Yes, and for important data you should. The webhook provides speed, the scheduled sync provides a periodic full check that repairs anything the webhook missed. Both must apply updates in a way that is safe to repeat.
Do automation tools like Zapier or Make handle this?
They support both triggers: instant triggers are webhooks, scheduled triggers are polling. They handle retries to a degree, but reconciliation and duplicate handling are still your design. For high volumes, per-operation pricing becomes the deciding factor.
Integration drifting or arriving late?
List the systems and what must move between them. In fifteen minutes we tell you which flows should be webhooks, which should be scheduled, and where a reconciliation job would stop the drift.
Book a free 15-minute call