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.
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