Before retrying an integration, find out what happened

A booking request leaves your system, but the reply never arrives. Before buying automation that writes to another system, ask how it handles this gap. A timeout after sending a request leaves the outcome unknown: the destination might have completed the work. Treating every missing reply as failure is a poor basis for another write.

Ask for a demonstration of how an uncertain operation becomes confirmed, safely retried or stopped for investigation. The buying decision should include that recovery behaviour, not just a successful connection.

Find the original operation before repeating it

In a hypothetical sandbox test, an integration asks a booking system to reserve a test appointment. The connection drops before a response arrives. The local screen shows a timeout; the destination may already hold the appointment. This is an invented test scenario, not a customer result.

Ask the implementer to keep the original operation reference and check the destination through its supported lookup or status mechanism. Match the intended appointment and its recorded state, rather than searching loosely by a person's name. If the lookup confirms completion, record that result without creating another booking. If it remains inconclusive, keep the operation marked unknown.

Require an explanation of what a missing search result proves. Do not accept an empty screen as sufficient evidence that the write never happened unless the provider's documented behaviour supports that conclusion. Where no reliable reconciliation route exists, agree how a person will investigate before another attempt.

Ask what makes a repeat safe

RFC 9110, section 9.2.2 distinguishes requests whose repeated intended effect is the same from those that lack that property. It advises against automatically retrying a non-idempotent request unless the client knows its semantics are idempotent or can detect that the original was never applied. A timeout alone does not establish either condition.

For a business buyer, this means asking what protects the particular booking, invoice or CRM write. Do not accept a blanket rule that automatically repeats every POST request. Ask for the endpoint-specific evidence behind the decision.

A provider-supported idempotency key can form part of that evidence, but its rules belong to that provider's contract. For a concrete documentation example, Stripe's idempotent-request documentation says its API v1 compares retry parameters with the original and can remove keys after they are at least 24 hours old. Reusing a pruned key generates a new request. This illustrates a limit to check, not a recommendation for a particular vendor.

Ask the implementer to preserve the same business intent, key and parameters for a supported retry. Have them verify the relevant endpoint, API version, retention window and error rules. Treat a changed request as a separate decision. Do not describe idempotency as an unlimited, exactly-once guarantee across the entire workflow.

Put a limit on recovery

Choose a finite attempt count and elapsed-time limit before launch. As a hypothetical test policy, you might allow at most one supported retry and stop recovery after ten minutes, whichever limit comes first. Those numbers are illustrative, not a universal safe setting. If the provider's required wait would exceed the deadline, stop and escalate rather than shorten the wait.

Require the implementation to follow the provider's rate-limit and retry guidance. For example, Stripe's rate-limit guidance recommends increasing delays with randomness when handling rate limiting. Do not turn that example into a fixed schedule for every system. Include status checks in the recovery budget so they cannot continue indefinitely either.

Name the person responsible when the budget expires, where they see the unresolved operation and who covers their absence. Give them the reference, intended action, attempt history and last supported readback. Ask them to reconcile the original before authorising anything new; an alert should not become permission to press retry repeatedly.

Bring a small recovery brief to the discussion

Before commissioning the work, collect:

• The systems involved and the exact business action each write should perform.
• The operation reference and supported way to check its destination state.
• The documented conditions for retrying, including idempotency and retention rules.
• The proposed attempt and time limits, plus the named escalation owner.
• A sandbox demonstration plan using invented records, with live customer operations, payments and messages excluded.

If you have not yet identified the steps, start with mapping the spreadsheet and email handoff. If a person must authorise recovery, use defining what an approval permits to make that permission specific.

Use the brief to discuss your existing systems through the API integration services page or contact James. Ask for a recovery approach that fits the actual interfaces before committing to the build.