Retry a failed integration without creating a second order
Plan for ambiguous timeouts, duplicate delivery and manual recovery with stable operation identifiers.
A timeout does not describe the business result
In this fictional example, an integration sends order O-104 to a fulfilment service. The service accepts it, but the response never reaches the sender. The sender sees a timeout; the receiver already has an order. Sending the same business operation again with no duplicate protection creates a second shipment request. Treat the result as unknown until it is reconciled with the receiver.
Separate the operation from its delivery attempts
Assign a stable operation identifier to the business action, such as dispatch-O-104-v1. Give each transmission its own attempt identifier for diagnostics. If the receiving API supports idempotency keys, use the documented field and retention rules. Reuse the operation key for a retry of that same action. A correction to the requested quantity is a new action and needs an explicit relationship to the earlier request.
Use the receiver's actual guarantees
Check how the receiver handles a repeated key, different payloads under one key, simultaneous requests and an expired deduplication window. Do not infer these rules from the word 'retry' in a connector interface. AWS's transactional outbox guidance warns that consumers still need to handle duplicate messages. Reliable delivery and a single business effect require separate design work.
Bound retries and route exceptions
Classify failures using the receiving API's documentation. A temporary service failure needs a different response from an invalid customer ID or denied permission. Set a maximum attempt count, spacing policy and owner for unresolved items. Keep the original operation identifier when the review queue sends a genuine retry. Repeatedly clicking a connector's run button is not a recovery procedure if every click creates a new business action.
Test the ambiguous cases
Use an isolated receiver or test environment. Try a duplicate request, a response lost after acceptance, an invalid payload and a request replayed after the receiver's deduplication window. For each test, inspect the number of resulting orders and shipments. A test that only checks the sender's success message misses duplicates on the receiving side. The expected result for the timeout case is one accepted operation and a reconciled status.
Keep a useful operations record
Retain the operation ID, attempt times, result classification and remote record identifier under your logging policy. Exclude passwords, tokens and unnecessary customer payloads. Give support staff a documented route to query the receiver before resubmitting an uncertain operation. When the receiver offers no idempotency feature, design a controlled reconciliation and manual review path instead of claiming exactly-once behaviour.