Request identities are one way an API can implement this behavior. Stripe, for example, supports idempotency keys on applicable requests under documented retention and parameter rules. (Stripe: idempotent requests ↗)
Jump to a section
Retrying after a lost response
Stripe-specific illustrative case: a create-customer request succeeds at Stripe but the response is lost. Retrying the same supported request with the same idempotency key can return the original result within Stripe’s documented rules, avoiding a second create; it does not make arbitrary actions safe to repeat forever.
A key has provider-specific scope and lifetime
Reuse the identity only for the same intended operation under the service’s rules. Changing the key after a lost response can create a second operation; reusing a key for a genuinely new operation can prevent the new work. Record the request identity and reconcile uncertain outcomes.
Test what happens after an uncertain response
Imagine the first request succeeds but the client times out before receiving confirmation. Retry the same operation in a test environment and inspect the stored result. The desired behavior is one completed change that can be confirmed, rather than two changes caused by one intention.