Integration

Webhooks vs. polling: designing reliable ERP integrations

When should an integration wait to be told something changed, and when should it go and check? A practical guide to choosing — and combining both.

What is the difference between webhooks and polling?

With polling, your integration asks another system at intervals whether anything has changed. With webhooks, the other system calls your integration when something happens — a payment is captured, an order is created.

Webhooks are faster and lighter. Polling is simpler to reason about and does not depend on the other side delivering anything.

Which should an ERP integration use?

Use webhooks for events where timing matters to a person: a payment confirmed at checkout, a kiosk sale, a status change a customer is waiting on.

Use polling, or a scheduled reconciliation, for anything that must be complete rather than fast — end-of-day totals, stock counts, ledger balances.

Most reliable integrations use both. Webhooks carry the event in near real time; a scheduled job confirms nothing was missed.

What makes a webhook integration reliable?

  • Verify the signature on every request before trusting it.
  • Respond quickly, then process from a queue. Senders retry when they don’t get a fast response, so slow processing creates duplicates.
  • Make processing idempotent. The same event delivered twice should post one invoice, not two. Store each event’s ID and skip ones you have already handled.
  • Store every event with its outcome, so failures can be investigated and replayed.
  • Expect events out of order. A “refunded” event can arrive before “captured”. Check the current state in the source system when order matters.

What makes polling reliable?

  • Use a “changed since” marker rather than re-reading everything.
  • Overlap the windows slightly so records updated at the boundary are not missed, and rely on idempotency to ignore repeats.
  • Respect rate limits and back off when the source system is under load.

What about systems that cannot send webhooks?

Many older ERPs cannot. Poll them on a sensible interval and publish what you find as internal events. The rest of your integration then works the same way regardless of the source — downstream services never need to know which systems push and which are polled.

A simple rule of thumb

Webhooks for speed, reconciliation for certainty.

If a missed event would cost money or trust, you need both: the webhook to act quickly, and the scheduled check to prove nothing slipped through.

Tell us where your operations break down.

Describe the problem in a few sentences. We will reply with an honest view of whether and how we can help.

Office
Karachi, Sindh, Pakistan
Book a consultation