Webhooks let a source system notify your application about an event. Polling has your application ask for changes at intervals. Choose using the required update delay and the source API’s actual capabilities. An integration may use webhooks for prompt updates and polling for reconciliation, but only if the provider exposes enough information for both.
Neither mechanism automatically guarantees that two systems remain consistent. Detection, processing, and recovery need separate decisions.
Compare the operational requirements
| Requirement | Webhook approach | Polling approach |
|---|---|---|
| Prompt changes | Receive notifications when the provider sends them | Delay depends on polling interval and processing time |
| Inbound connectivity | Usually needs a reachable receiver | Can often operate with outbound requests only |
| Missed updates | Check retry and replay capabilities | Check history, pagination, and change cursors |
| Duplicates | Make repeated delivery safe | Make overlapping fetch windows safe |
| Deleted records | Verify deletion events exist | Verify tombstones or another deletion record exists |
| Load limits | Account for event bursts | Budget API requests across all synchronized objects |
Read the documentation for the specific provider. For example, Stripe documents webhook retries, duplicate events, and delivery-order limitations. Those details are provider behavior, not universal promises for every webhook API.
Separate receiving an event from applying it
For an important update, first verify the message and durably record the work. Then process it according to the application’s rules. An acknowledgement should mean the receiver has accepted responsibility, rather than that an entire downstream workflow necessarily finished.
Record a stable event or operation identifier so that a repeated message does not repeat the business action. Define what happens when two different events describe the same underlying change. If an older event arrives after a newer one, the implementation needs a way to avoid overwriting current state with stale information.
Design polling around a checkpoint
Define the field or cursor used to find changes, the ordering of results, and the point at which progress is saved. A page of results should not be considered complete before its records have been handled safely.
For a hypothetical hourly customer sync, test an update made while the poller is paging through results. Also test two records with the same update timestamp. A simple “later than the last timestamp” filter can miss records unless the API contract and checkpoint strategy account for ties and concurrent changes.
Prove that recovery works
Pause the receiver, delay the downstream system, resend an event, and force a failure halfway through a fetched page. Check that operators can see the unresolved work and restore consistency without silently duplicating actions.
A reconciliation job is useful only if it can identify discrepancies. Agree what it compares, how far back it looks, how deletions appear, and what happens when the source no longer retains the necessary history.
What should the integration brief include?
Specify acceptable staleness, provider limits, event types, initial backfill, recovery ownership, and evidence of successful processing. Use the API integration checklist for the broader questions about access, mapping, and failure handling. Choose the transport after those requirements are clear.
Put it into practice.
Explore our api integration services service or send us the problem you are working on.