FF144 Idempotency-Key - draft docs

[hamishwillee]

FF135 adds support for the Idempotency-Key header behind a preference - I'm working on this because there was an abortive attempt to ship in 145.

This allows a client to make a POST or PATCH request idempotent, so that if the client doesn't receive a response it can safely resend the request without having to worry about whether the server already acted on it and the response was just lost.

The key is sent in each new requests to indicate that a POST/PATCH is a particular unique command. If the server gets the same request with the same key it doesn't act on it after the first time, but responds as though it had. The key and error response format is defined by the server.

Related docs work can be tracked in #41497

[github-actions]

Preview URLs

• /en-US/docs/Web/HTTP/Reference/Headers/Idempotency-Key
• /en-US/docs/Web/HTTP/Reference/Headers

Flaws (6)

URL: /en-US/docs/Web/HTTP/Reference/Headers
Title: HTTP headers
Flaw count: 3

• macros:
  • Can't resolve /en-US/docs/Web/HTTP/Reference/Headers/Accept-Signature
  • Can't resolve /en-US/docs/Web/HTTP/Reference/Headers/Signature
  • Can't resolve /en-US/docs/Web/HTTP/Reference/Headers/Signed-Headers

---

URL: /en-US/docs/Web/HTTP/Reference/Headers/Idempotency-Key
Title: Idempotency-Key header
Flaw count: 3

• unknown:
  • No generic content config found
  • no blog root
  • no blog root

(comment last updated: 2025-10-24 06:13:22)

[hamishwillee]

FYI NOrmally an app would set the header in JavaScript. Firefox currently does this automatically, but of course NOT to whatever standard is defined by the server. I added a note in the BCD entry for this, but the behaviour on release isn't known, so I haven't commented here. Kept a note to remind me.