A connection asks finance to create an invoice. Finance creates it, but the response is lost. Retrying the request may create a second invoice. The timeout describes what the caller received, not what the destination did.
Use the destination’s protection
Some APIs accept an idempotency key. Store it before the first request and reuse it for retries of the same action. Generating a new key on every attempt removes that protection.
Check the provider’s retention window and rules for changed payloads. The same key with different details may be rejected or return the earlier result; it is not necessarily an update.
A lookup can support recovery
Other systems support searching by a unique source reference. This helps only if the reference is preserved and the lookup is reliable. Matching a customer name or amount is not enough to establish identity.
If neither repeat-safe requests nor a reliable lookup are available, stop automatic retries for the uncertain case and ask finance to review it.
Keep the evidence together
Save the source reference, request key and confirmed destination reference. Distinguish not attempted, confirmed complete and result uncertain. An operator needs to see whether another attempt could repeat a financial action.
Test a response lost after posting and a retry after the retention window. The recovery route can differ. Add both to the acceptance checks.