Idempotency keys

Glotto treats the Idempotency-Key header as a first-class concept, so retrying a mutation can’t accidentally create two of something. When an operation’s spec advertises the header, the generated SDK auto-injects a fresh UUID on each POST, and the server dedupes on it.

How it interacts with retries

Glotto ships built-in retries — but deliberately not blind ones:

• Safe methods (GET / HEAD) plus 5xx and retryable transport errors are retried with exponential backoff + jitter, out of the box.
• Mutations are retried only when their OpenAPI spec advertises Idempotency-Key (so the server can dedupe a replayed request). Mutations without the advertised header are not retried by default — configurable via client_settings.

This pairs Stainless-style “retries out of the box” with the safer “don’t retry blindly” discipline: the SDK auto-injects the key, callers (and the SDK) can retry, and the server dedupes.