Run a scheduled reconciliation job. Every few minutes or hours, list recent objects from the provider's API, compare them with your records, and fix the differences. Webhooks are retried for a limited window, so an outage longer than that window leaves permanent gaps unless you poll as a backstop.
Why webhooks alone are not enough
Webhook delivery is best effort over a network you do not control. Two published examples show the limits.
One payment provider attempts delivery for up to three days with exponential backoff in live mode, but sandbox events are retried only three times over a few hours. After the window, the event is not delivered again unless you retry it by hand. Its documentation also describes manual retries from the dashboard and says you can retrieve missing objects through the API.
A messaging platform's events API expects a 2xx response within three seconds and retries a failed delivery three times: nearly immediately, after one minute, and after five minutes. It also warns that an app whose success rate falls too low can be temporarily disabled, although apps receiving fewer than 1,000 events per hour are not disabled automatically.
So a two hour outage on your side can lose events on one platform and be fully recovered on another. You cannot design around vendor specifics. You design around the possibility of loss.
The reconciliation pattern
- Pick the source of truth. For payments, the provider's object is the truth. Your database is a cache of it.
- Record a high water mark. Store the creation time or cursor of the last object you reconciled.
- List forward. Page through objects created or updated since that mark, using the list endpoint with pagination.
- Compare by ID. For each object, look up your record. Missing or different status means a missed or failed event.
- Apply through the same handler. Feed the object into the code path your webhook handler uses, so there is one place that changes state.
- Alert on drift. A reconciliation run that fixes more than a handful of records is a signal that webhooks are failing.
How often should it run?
Match the cost of being wrong. A job every five to fifteen minutes suits payment status. A nightly job may be enough for low stakes data such as marketing preferences. Always overlap the window slightly, for example looking back an hour, so objects created during the last run are not skipped. Idempotent handlers make overlap harmless.
Mind the rate limits
Polling uses API quota. Use pagination, filter by time, and honor rate limit responses with backoff and jitter. See webhook retry schedule, backoff and jitter.
Watch the failure signals
Track the delivery failure rate in the provider dashboard and in your own logs. A slow handler is a common cause of timeouts, so acknowledge quickly and process from a queue. Disabled endpoints are another: if you remove a failing endpoint, remember that a disabled destination stops future retries for that event.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a scheduled recheck catches change that a one time scan would miss, the same idea as polling behind webhooks.
Where Safeguard fits
Integrations are part of your attack surface. Safeguard's asset discovery and continuous dependency scanning help you keep track of what runs and what it depends on. You can start with a free scan.
Quick check
Do I still need reconciliation if my provider retries webhooks?
Yes. Retries stop after a window, and your own bugs can drop events the provider considers delivered. Polling is the backstop.
Should the reconciliation job use different logic from the webhook handler?
No. Route both through one function that applies state changes, so there is only one place to get it right.
Sources
- Receive events in your webhook endpoint, Stripe documentation
- Events API, Slack developer documentation
Last reviewed: 19 October 2026.
