Skip to main content
Use idempotency keys when retrying write requests on endpoints that document server-side idempotency support. This prevents duplicate writes when a network failure leaves the original request outcome unknown. 
Idempotency-Key: 8b6e0c46-6e1e-4a64-a949-9cf4f4cb49e5
Keys should be:
  • unique per logical operation
  • stable across retries of the same operation
  • generated by the client, not reused globally
  • stored long enough for your retry window

​
Preview Status

Idempotency behavior is being standardized across Public Preview write endpoints. Until an endpoint marks Idempotency-Key as supported, treat the header as a client-side correlation key and future-compatibility convention, not a server-side dedupe guarantee.

​
Retry Rules

SituationUse same key?
Request timed out before responseYes
Received 500, 502, or 504Yes
Received 429 and retrying after backoffYes
Validation failed with 400No, fix the request first
User changed the operationNo, create a new key