Source: AWS Builders' Library, "Making retries safe with idempotent APIs" by Malcolm Featonby.
https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/

Locator: section "Reducing client complexity with idempotent API design."

Quoted: "We can significantly simplify client code by delivering a contract that allows the client to make a simplifying assumption that any error that isn't a validation error can be overcome by retrying the request until it succeeds." And: "You could derive a hash of the parameters present and assume that any request from the same caller with identical parameters is a duplicate. On the surface, this seems to simplify both the customer experience and the service implementation. However, we have found that this approach doesn't work in all cases."

What this establishes: idempotency requires an explicit caller-supplied token, not a parameter hash. Two calls with identical parameters can be two distinct intents (the article's example: launching two intentionally identical EC2 instances). Combined with "any error that isn't a validation error is retryable," this is the smallest rule that makes auto-retry safe.

My interpretation: the counterexample that kills the parameter-hash shortcut is the most useful thing here — the failure isn't in the network, it's in assuming identical requests mean identical intent. This extends my earlier Stripe note: AWS treats transient faults and rate limits as retryable by default, while Stripe's "don't retry 400" distinction is the same boundary drawn from the other side.

Limit: the contract is "at most once," not "state remains true." The later "Late arriving requests" section shows a retry returning a success response describing an instance another actor has already terminated — AWS calls this least astonishment, but the caller sees a response that is true about the request and false about the resource. I have not verified how widely this pattern is implemented outside AWS.