Errors
Gateway errors share one JSON envelope, carry a stable code you can branch on, and tell you whether the failure came from Gateway or from the upstream provider. This page is the aggregate reference; each feature page covers its own errors in context.
Before you write retry logic, read what fails over: under a routing policy, Gateway already retries some of these failures on another route.
The error envelope
Model API errors (/v1/responses and every compatible surface) return:
typeis the broad category (invalid_request_error,authentication_error,budget_exceeded,blocked_by_policy,rate_limit_error,not_found_error,provider_error,internal_error).codeis the specific, stable identifier. Branch oncode, not onmessagetext.sourceis"gateway"when Gateway rejected the request itself and"provider"when the upstream provider failed;providerthen names the vendor.
The Management API (/v1/keys, /v1/projects, /v1/routing-policies, /v1/customers) uses FastAPI’s {"detail": ...} shape instead, with structured codes on the cases worth branching on (for example 409 PROJECT_HAS_ACTIVE_API_KEYS).
Authentication: 401
Payment and budgets: 402
Responses include remaining-headroom headers as limits approach: X-Credit-Balance-USD, X-Project-Budget-Remaining-USD / X-Project-Budget-Limit-USD, X-Key-Limit-Remaining-USD / X-Key-Limit-USD.
Invalid requests: 400
Policy and permission blocks: 403 and 422
Not found: 404
Too large and too fast: 413 and 429
Provider failures: 5xx
What fails over
Under a Priority or Intelligent routing policy, some failures are retried on the next candidate route instead of being returned to you. That is why a request that failed on one vendor can come back answered by another, and why client-side retries on these statuses usually duplicate work Gateway already did. A direct model call, with no policy resolved, returns the failure as-is.
On the three 200-shaped cases, exhausting every candidate serves the last response received rather than converting it into an error, so you get the refusal or the schema-violating body. Each discarded attempt is billed at the route that ran it.
Errors during streaming
A streamed request is validated before the stream opens. If the first frame from the provider is an error, or Gateway rejects the request on capability, budget, or policy grounds, no SSE stream is opened and you get the same HTTP status and body a non-streaming request would return.
Once the stream is open the status has committed as 200, so a later failure arrives as an in-stream frame: response.error on the native API, a response.failed event on the OpenAI Responses surface, and an Anthropic-shaped error event on the Anthropic surface. See Streaming for each surface’s exact contract.
Degraded requests: warnings
Not every problem is an error. When Gateway serves a request but changes it on the way, a dropped tool, a clamped reasoning level, a stripped cache marker, the response carries a warnings array instead of failing. See Warnings for the code list and where warnings arrive on each surface.