The decision that matters
Assign a stable idempotency key to one logical operation and reuse it when retrying that operation. Store enough information to return the prior result or identify an in-progress attempt. Scope the key to the organization and operation, and reject reuse with different material parameters. The implementation must handle concurrent requests for the same key, not just a retry that arrives after the first request finishes.
A practical scenario
An administrator clicks Send invoice, but the browser loses its connection. Retrying with a new identifier could send a second email. Retrying with the same logical operation key lets the system recognize the attempt. If the provider outcome remains uncertain, show that state and reconcile it rather than claiming either guaranteed failure or guaranteed delivery.
Before you ship
- Keep the key stable across retries of the same intent.
- Use a uniqueness constraint or equivalent atomic guard.
- Define how uncertain provider outcomes are reconciled.
A useful next step
Test a dropped response and two concurrent submissions. Inspect both the application record and the external side effect. A disabled button helps the interface, but safe retry behavior must also exist on the server.
Primary reference & further reading
This guide combines general engineering recommendations with an illustrative scenario. Provider behavior can change; check current documentation before applying it. Read our editorial approach.