Find your code
Every error body carries the same machine-readable block, described in the error body. One case returns
200 with the failure inside the body. See a stream that fails after it starts.
validation
Something in the request is wrong. Fix it and resend.authentication
A key is missing, wrong, or refused. It’s either your FlexInference key or a provider key you stored.permission
Your key is valid, and this request still isn’t allowed. Adding funds doesn’t clear these.billing
Your balance ran out.quota
You hit a ceiling. The same request can succeed after a wait.capability
This model or route can’t do what you asked. Something in the request has to change.upstream
The fault is between us and the provider. Nothing is wrong with your request.internal
The fault is on our side. A repeat is worth reporting.canceled
You went away before the response finished.The
provider array pins your route. openai, anthropic, google,
cloudflare, and deepinfra are direct routes. vertex, bedrock, and
foundry run the same models through Google Vertex AI, Amazon Bedrock, and
Azure AI Foundry on your own cloud key. See backup
providers.The error body
Errors come in the shape of the endpoint you called. The OpenAI endpoints return the OpenAI shape and/v1/messages returns the Anthropic shape. The Google paths return the Google shape and the Converse paths return the AWS shape. Provider errors follow the same rule.
OpenAI shape (/v1/responses, /v1/chat/completions)
Anthropic shape (/v1/messages)
Google shape (/v1/interactions, :generateContent)
AWS shape (/model/{modelId}/converse)
type uses the stock OpenAI categories plus two of ours. billing_error means a managed balance ran out, and flexinference_error means an internal or upstream fault. The AWS shape has no error wrapper. Its type goes in the x-amzn-errortype header.
The flexinference block
Every error carries oneflexinference object, the same on all six endpoints.
A stream that fails after it starts
A streaming response returns200 as soon as the first bytes leave. HTTP gives no way to take that back. So a failure after that point reaches you in the body, not in the status.
The stream ends with a terminal error event in your endpoint’s shape. It carries the same flexinference block a refused request has. Its status field says what the failure would have returned before the stream started.
A streamed generateContent call ends with the Google error body as its last chunk. A converse-stream call ends with an event-stream exception frame (what the AWS SDKs raise on).
Your SDK raises on that event. None of them hand you the flexinference block though, so read the raw event to get the code. The chunks that arrived before the raise are the whole answer.
The dashboard logs the request as failed with this code, not as the 200 that went out first.
Provider errors
A provider error keeps its status and message and comes back in your endpoint’s shape. Call/v1/messages with an OpenAI model and its error comes back Anthropic-shaped.
A passed-through provider error carries the block too, with origin reading provider and their code in provider_code.
Flex outcome headers
Successful200 responses carry these on every endpoint, streaming or not.
x-flexinference-flex-reason values:
A duration that can’t race at all returns
400 instead:
flex_model_not_capable off the flex list,
flex_unsupported_for_anthropic on your
own Anthropic key,
flex_anthropic_streaming_unsupported
with stream: true, and
flex_anthropic_deadline_too_short
under 180 seconds.