Safe Retries

Failed Requests

Usage is reserved before each call and settled only when the call succeeds and produces usage. A timeout, dropped connection, or 5xx before that releases the reservation. See How the API Works.

`Idempotency-Key`

On public inference, a supplied Idempotency-Key is validated as a UUID but not used to deduplicate. Each request runs and is metered separately.

Retrying

Retry timeouts, dropped connections, 429, 502, and 503 with backoff. On 429, wait for Retry-After.
A call that completed on the server but whose response was lost will run again on a blind retry. When you cannot tell, check state first.
For an operation that must not run twice, record a client-generated operation ID once the call succeeds and check it before retrying.

import time, httpx

def call_with_retry(url, payload, headers, attempts=4):
    for i in range(attempts):
        try:
            r = httpx.post(url, json=payload, headers=headers, timeout=60)
            if r.status_code in (429, 500, 502, 503, 504):
                raise httpx.HTTPStatusError("retryable", request=r.request, response=r)
            r.raise_for_status()
            return r.json()
        except (httpx.TransportError, httpx.HTTPStatusError):
            if i == attempts - 1:
                raise
            time.sleep(2 ** i)  # exponential backoff

How the API Works

Reserve, run, settle.

Error Reference

The code families.

Rate Limits

Retry-After and the limit headers.

Uptime and Fallbacks

Failover without weakening privacy.

Basics

Features

Server-Side Tools

Multimodal

Best Practices

SDKs

API Reference

Safe Retries

Failed Requests

`Idempotency-Key`

Retrying

How the API Works

Error Reference

Rate Limits

Uptime and Fallbacks

​Failed Requests

​Idempotency-Key

​Retrying

​Related

How the API Works

Error Reference

Rate Limits

Uptime and Fallbacks

Failed Requests

`Idempotency-Key`

Retrying

Related