Webhooks are useful notifications, but an integration also needs a way to notice when its local view has drifted. A configuration error or processing failure can leave one record stale even after the main event stream is healthy again.
A reconciliation job checks selected source state against the application's stored view. It should have a clear scope and request budget.
Choose important records first
Start with data whose correctness matters to the product. Recently active records or unfinished processing jobs may deserve more attention than an entire historical catalog. Use only lookup and listing operations the API actually documents.
Keep a checkpoint so the job can continue after an interruption. Bound batch size, concurrency, and retries. A recovery job that overloads the service can create another failure instead of fixing the first one.
When a mismatch appears, record what differs and apply a reviewed repair rule. Do not treat every difference as permission to overwrite listener choices with catalog metadata. Compare fields that belong to the same source of truth.
Test a deliberate gap
In a controlled environment, skip one event and change the source record. Run reconciliation and verify that it detects the stale local view. Then interrupt the repair and repeat the job. The repeated run should remain safe.
Measure the age and count of unresolved mismatches. Those values can reveal a processing problem earlier than a broad “service is up” check.
Reconciliation does not replace signature verification or normal event handling. It provides a second route to detect incomplete work. Document how quickly important data is expected to converge instead of promising that every change is reflected instantly.