A server saves an enquiry, but the response is lost. The browser cannot tell whether saving succeeded. Retrying is reasonable, yet an ordinary second request may create another record.

An idempotency key gives the server a way to recognize another attempt at the same logical operation.

Define the operation first

For a lead form, one key can represent one enquiry submission. It should not represent every enquiry from the same email address forever.

A useful contract is: unchanged retries reuse the key; a new enquiry uses a new key. If the user edits the payload after an uncertain outcome, define an explicit recovery process instead of silently attaching different data to the old operation.

The key is an opaque identifier. It should not contain an email address, telephone number, or message text.

Bind the key to its context

Store the key within the appropriate tenant or caller scope, alongside a request fingerprint and processing state.…