How to Find API Changes That Never Reached Your Integration

An integration dashboard shows no failed events. The receiving team still has outdated customer records.

The dashboard may be accurate about everything it received. It cannot report an error for a change it never knew existed.

Before accepting an integration between business applications, agree how the team will discover missing work. That decision affects the source API, the evidence you retain and what an operator can recover after an outage.

Define the changes the destination should receive

Start with one handoff. Identify the source application, the receiving application, the records in scope and the fields each application owns. Agree how long the destination can remain out of date before someone needs to act.

Then distinguish two requirements. Does the destination need the latest customer address, or must it process every address-change event? Reading today's source record may repair the current address. It cannot reconstruct intermediate changes unless the source retains and exposes them.

That distinction determines what completeness means. A current-state synchronization needs evidence about the selected records and fields. An event-driven business process needs evidence about the required events and actions. Choose the contract before choosing a monitoring percentage.

Check what the source makes recoverable

Webhook recovery rules vary. Stripe documents automatic retries, duplicate deliveries and delivery without a guaranteed event order. GitHub documents that failed webhook deliveries are not automatically redelivered.

Those are provider-specific behaviors. Neither a generic retry policy nor the existence of a webhook establishes how your integration will discover missed work.

For each source, record whether you can enumerate relevant records or events after an interruption. Check access, retention, pagination, filters and deletion behavior. Confirm what a saved cursor or timestamp represents. A field named updated_at does not establish that you can obtain every historical change or a consistent snapshot.

If the source exposes only current state, describe recovery as current-state reconciliation. If neither history nor a complete current-state comparison is available, record the gap explicitly. A receiver log cannot supply evidence the source never exposed.

Separate missing changes from rejected changes

Consider this hypothetical acceptance test. The source contains 100 distinct, in-scope customer changes for an agreed test window. The receiver durably records 98. It applies 95 and rejects three because required fields are missing. Two never reach it.

Receipt coverage is 98%. Confirmed application is 95%. These percentages describe the agreed synthetic dataset, not production performance or a promised service level.

The two missing changes and three rejected changes need different treatment. The rejected records have reached a known validation decision. Retrying them without resolving the input will not supply the missing fields. The missing records need investigation at the source and delivery boundary before anyone can assume that replay is available.

This example assumes one intended destination change per source change, with no approved skips. A real workflow may filter records, combine changes or create several actions. Write those rules into the expected set rather than treating every source event as a required destination write.

Compare identities, then the fields that matter

Counts alone cannot establish completeness. A destination containing 100 records could still contain the wrong customers. A received event can also exist in the log while its destination write remains incomplete.

Use stable source identifiers, including tenant scope where required. Compare the expected identities with receiver evidence and destination references. Then compare the fields owned by the source using the agreed mapping. Do not compare raw payloads when the destination legitimately transforms the data.

Set an explicit comparison boundary. With a known test dataset, the team can control changes while collecting evidence. In a live system, records may change while pages are being read. Use the source's documented snapshot or cursor semantics where available. Otherwise, describe the overlap, repeated checks and limits of the method. Do not call an inconsistent export a complete snapshot.

Include deletions and access changes. A record absent from an API response may have been deleted, moved out of scope or become inaccessible to the integration account. The operator needs enough evidence to distinguish those possibilities before removing destination data.

Give unresolved work an owner

A useful exception record connects the source change to the last confirmed stage. It identifies the destination reference where available, the problem, the next permitted action and the person responsible. Store only the information needed for diagnosis and recovery, under appropriate access and retention rules.

Keep uncertain outcomes visible. If the destination may have accepted an operation but its response was lost, investigate the destination before repeating a consequential action. Detecting a missing confirmation is different from proving the action never happened.

The acceptance review should exercise the following cases in a test environment:

These are proposed acceptance cases, not results from a tested implementation. The source and destination capabilities determine which controls can be built.

Make completeness part of the handover

Our guide to finding silent background job failures covers investigating work that ran without producing its intended result. This review starts earlier: identifying source changes that may never have entered the receiver's execution history.

Ask for the expected-change contract, the source recovery limits, a comparison result and the unresolved exception list before signing off. Another operator should be able to explain what is missing and who owns the next action.

If that review exposes a gap across your operating applications, bring one handoff, its source documentation and a sample discrepancy to a conversation with Better Software. Those inputs make it possible to scope the engineering work and its limits.