Webhooks or polling: designing integrations between business systems that do not lose data

Two ways to learn that something changed

When a customer pays, a lead fills in a form or a shipment is delivered, another system often needs to know. There are two basic ways to find out. With polling, the receiving system asks the source system at intervals whether anything has changed. With webhooks, the source system sends an HTTP request to a URL provided by the receiving system as soon as an event occurs.

Both approaches are widely supported. Payment providers, e-commerce platforms, CRMs, form tools and shipping services commonly offer webhooks, and almost all systems with an API allow data to be fetched on request. The choice affects speed, cost, reliability and how failures show up.

Polling: simple and predictable, but slow or wasteful

Polling is easy to understand and control. The receiving system decides when to ask, handles its own schedule and can fetch everything changed since the last successful run. If it is offline for an hour, it catches up on the next run.

Its weaknesses are latency and load. Polling every few minutes delays updates, and polling every few seconds wastes requests and can hit API rate limits, especially with many accounts or objects. Detecting changes also requires the source API to support filters such as modified since timestamps, and not every API does this well.

Polling remains the right tool for systems without webhooks, for periodic data such as daily exchange rates or stock levels, and as a safety net for event-driven integrations.

Webhooks: fast, but delivery is not guaranteed

Webhooks deliver events almost immediately and avoid unnecessary requests. They are well suited to payment confirmations, order creation, form submissions and status updates where speed matters.

The risks are easy to underestimate. The receiving endpoint may be down during a deployment, time out under load or return an error. Providers typically retry failed deliveries for a limited period, but retry policies differ, and after the final attempt the event may be lost unless it is recovered another way. Events can also arrive more than once or out of order.

Security is the other concern. A webhook URL is publicly reachable, so the receiver must confirm that requests genuinely come from the provider and have not been altered.

Verify signatures

Check the signature many providers include, usually an HMAC of the payload with a shared secret, and reject requests that fail.

Respond fast

Acknowledge receipt quickly and process the event in the background, so provider timeouts do not trigger retries.

Be idempotent

Store event identifiers and ignore events already processed, so retries and duplicates do not create duplicate orders or emails.

Handle order

Use timestamps or version numbers, or fetch the current state from the API, rather than assuming events arrive in sequence.

Log everything

Keep raw events and processing results so failures can be investigated and replayed.

Combining both: event plus reconciliation

Robust integrations rarely rely on webhooks alone. A common pattern treats the webhook as a notification that something changed, then fetches the full, current object from the source API before updating the receiving system. That avoids acting on outdated payloads and handles out-of-order events.

Alongside the webhook flow, a scheduled reconciliation job compares records between systems, for example all orders and payments of the past day, and repairs gaps. If a webhook was lost during an outage, reconciliation finds the missing record. If an event was processed twice, reconciliation detects the duplicate.

This combination gives the speed of webhooks with the reliability of polling. The reconciliation schedule depends on business impact: hourly for payments and orders, daily for less critical data.

Where integrations commonly fail

The first failure is silent loss. An endpoint returned errors for a day after a deployment, the provider stopped retrying, and nobody noticed until customers complained. Monitoring should alert on failed deliveries, processing errors and unusual drops in event volume.

The second is duplicate side effects. A retried payment webhook creates two orders, sends two confirmation emails or triggers two shipments. Idempotency keys and checks against existing records prevent this.

The third is hidden dependency on one person’s account. Webhooks were configured in a provider dashboard under an employee’s login, secrets were stored in a spreadsheet, and nobody knows what is connected. Integration settings, secrets and endpoints should be documented, owned by the organisation and stored in proper secret management.

Choosing an approach

Use webhooks where speed matters and the provider supports them well, with signature verification, fast acknowledgement, idempotent processing and logging. Use polling where webhooks are unavailable or data changes on a predictable schedule. For business-critical data such as payments, orders, invoices and customer records, add reconciliation regardless of the primary method.

Integration platforms can reduce the effort of connecting common tools, but the same principles apply inside them. Ask how a platform handles retries, duplicates, failed runs, replay and monitoring before trusting it with revenue data.

Where this sits in what we do

This article covers one decision inside a wider engagement. The solution page sets out how that engagement runs, what it includes and what it costs to find out.

• Custom Business Platform — A platform built around how your business actually runs — customer portal, internal tooling, database and the automation between them.
• Quote to cash without re-keying: where the handoffs break
• Product data is the e-commerce growth lever nobody budgets for
• Moving a website, email or domain without downtime: the DNS steps that usually go wrong
• Website uptime and certificate monitoring: catching outages, expiring certificates and broken checkouts first
• All insight articles