A client can lose a response after the server has already applied a change. Retrying a create or charge without coordination may produce a duplicate, even though the user clicked only once.

Define one key per intended operation

  • Generate a random key when the user starts an operation and reuse it for retries of that same operation.
  • Have the server store the key with the result and reject reuse with a different request body.
  • Choose and document a retention period that covers the expected retry window.

Return a consistent result

When the same key arrives again, return the original result or a documented in-progress response rather than running the mutation again. Do not treat a key as authentication; authorize each request independently.

Test response loss and repeated requests at the server boundary. A button lock can reduce accidental clicks, but it does not replace server-side idempotency when networks retry.