A missing response may mean the request never arrived, is still running or completed with a lost response. A timeout does not establish the outcome. Three mechanisms answer three different questions.

Idempotency: can I repeat safely?

Repeating the same operation should not create an additional effect within the API’s guaranteed scope. A stable identifier distinguishes a retry from a new business attempt. Define scope, retention, concurrent requests and identifier reuse with different payloads. An identifier without provider-side handling does not guarantee safety.

Lookup: what happened to the original operation?

Checking by operation identifier can establish success, confirmed failure or an unknown result. “Not found” need not mean “not executed”: its meaning depends on completeness, delay and the contract. Unresolved operations require reconciliation rather than a blind new request.

Compensation: how do I correct a business effect?

Compensation is a new operation correcting an earlier effect. It can fail and needs its own identity, preconditions and retry handling. Reversal in one API does not necessarily mean refund or cancellation in another.

Example and limits

Practice-inspired educational scenario: payment was collected but it is unknown whether a booking exists. This example’s contract permits bounded idempotent retries, then lookup, and payment reversal only after unequivocal confirmation that no booking was created. This is an exercise assumption, not a universal payment procedure. Do not create another booking after confirmed success; retain unknown outcomes for reconciliation.

Practise an unknown outcome → · Source: AWS — safe retries