Errors
Standardized across every provider, with a request ID on every failure and explicit retry semantics.
Error shape
{
"error": {
"type": "rate_limit",
"message": "key requests limit of 600 per minute exceeded; retry in 2s",
"code": "rate_limit",
"param": "requests",
"request_id": "req_01J9F3KJ2MQ8ZV5T7XB0N4A6WD",
"retriable": true
}
}
// plus X-Request-Id on every response; on a 429 also Retry-After
// and X-RateLimit-* (see Rate limits & quotas)Idempotency
Send Idempotency-Key on any inference call. The key is claimed per organization before the request is written and kept for 24 hours. A second call with the same key and the same body is a replay: the stored status and body come back with Idempotency-Replayed: true and the original's X-Request-Id, an originally streamed request is replayed as a compact SSE stream ending in the same final frame, and no rate-limit token, wallet hold or charge is consumed. The same key with a different body is 409 code: "idempotency_key_reused" (param: "Idempotency-Key"); while the original is still in flight it is 409 code: "idempotency_in_progress" with retriable: true — retry after about a second. Only successful responses are stored, so a request that failed may be retried with the same key.
POST /v1/chat/completions
Idempotency-Key: order-8812-summary # any string unique to the operation, per organization
# first call → 200, X-Request-Id: req_01J9F3KJ…
# same key + same body within 24 h → 200, the stored body, plus
Idempotency-Replayed: true
X-Request-Id: req_01J9F3KJ… # the original request
# same key + different body → 409 idempotency_key_reused
# original still running → 409 idempotency_in_progressPartial streams that disconnect are metered for the usage observed and reconciled against the provider's final report.