Retrying integrations without repeating the work

A timeout leaves a question

A missing response does not establish whether the remote operation completed. Treat that uncertainty as an explicit state rather than immediately creating another operation.

Identify the operation

Where a provider supports idempotency keys, reuse the same key for retries of the same intended operation. A new business operation needs a new identity. Persist that identity before sending the request.

Read the provider's contract

Key retention, parameter matching and error replay vary by API. Stripe's documented behavior even differs between API versions. Choose retry rules against the specific integration contract; avoid assuming every failed response is safe to repeat.

Make uncertainty testable

A useful review exercise is to trace the operation through these cases before choosing a retry policy:

• The remote service completes, but its response is lost.
• Two workers submit the same operation concurrently.
• A retry arrives after the provider's key retention window.
• An operator needs to reconcile an unresolved result.