Optional unique key for best-effort POST retry protection. Redis reserves the key, the request runs with ordinary service transactions, then the successful response is cached separately for 24 hours by default. There is no request-wide transaction or atomic commit between the operation and its replay result. A matching cached response is replayed verbatim with Idempotent-Replayed: true. Redis loss/eviction or retention expiry can remove protection and allow re-execution. Uploads and chunked bodies are covered; multipart boundaries and JSON property order may differ. Retries still pass validation and current authorization; a later 403/404 does not undo the original operation. A changed payload returns 422 idempotency_key_mismatch. A recent active reservation returns 409 idempotency_key_in_use with Retry-After. A retry with an unresolved key, including an unfinished reservation older than 5 minutes, returns 409 idempotency_outcome_unknown without Retry-After. This timeout does not release the reservation or permit re-execution while it is retained. Inspect the affected resource before starting a new operation; do not blindly reuse an unresolved key after expiry. A 4xx rejection releases the reservation, allowing the same key to be retried after correcting the cause. A 5xx or interruption after execution starts leaves it unresolved. An unavailable reservation store returns 503 before execution; an oversized request returns 413. Cache-save failure or a response over the cache limit preserves the original success status, headers and body; only future retries become unresolved. When idempotency is explicitly disabled by server configuration, the header is ignored and requests execute normally without retry protection. Use a new unique key for each intended operation.

Generated from available response content types