Networks make outcomes uncertain
A request may reach the server and commit successfully even when the browser never receives the response. Retrying is reasonable, but without a stable request identity the server cannot distinguish a retry from a new command.
For public link creation, that ambiguity can produce duplicate aliases, confusing records, or repeated side effects.
One key represents one intended mutation
The client sends a unique idempotency key with the create request. The server stores the result together with a fingerprint of the input. Repeating the same key and input returns the original result.
Using the same key with different input is rejected as a conflict. This protects both the client and the server from accidentally changing the meaning of a previous command.
Durability matters in production
An in-memory idempotency store is enough for isolated tests, not for a multi-instance production service. The production key and result must live in the same durable domain boundary as the mutation, with expiration and tenant scope.
The same pattern applies to payments, webhook processing, imports, and jobs where a duplicate effect would be costly.