Idempotency and safe retries
The current v6 OpenAPI contract does not define a standard idempotency-key header. Treat mutating requests as potentially non-idempotent unless the endpoint description explicitly says otherwise.
Retry safely
- Save the response’s task ID before retrying a background operation.
- On a timeout, retrieve the existing resource or task before starting another operation.
- Use a client-side correlation ID in your own logs so an operator can trace one user action.
- Retry
429,503, and documented transient conflicts with bounded backoff. - Do not automatically retry a restore, migration, or destructive request when the outcome is unknown.
If a future API version adds idempotency keys, the header name, retention period, request-matching behavior, and conflict response will be documented here and in the affected operations.