Choose an error format
Choose by endpoint, not by model provider. A Gemini image model called through LinkModel’s task API uses that task endpoint’s response format, not the Gemini-native error format.
The same format applies to gateway rejections and model-service errors on the compatibility endpoints listed below. For file APIs, legacy endpoints, Decisions, and other endpoints not listed there, follow the individual API Reference response schema.
LinkModel task API errors
For task creation, the response uses these fields:Example: validation failure with HTTP 200
A task creation request can return HTTP200 with business code: 400. Treat it as a failed request and correct the parameters.
code: 0 and a task_id, poll the task endpoint and inspect data.status. A successful query can report a failed generation task.
Message fields vary by endpoint. For example, the video task query uses top-level message for the query result and data.msg for task details or errors; task creation uses top-level msg. Follow the endpoint’s schema rather than assuming one message field works everywhere.
The compatibility API status mappings below do not replace task API behavior. For example, task creation can return HTTP 500 for insufficient balance, while the covered compatibility endpoints use HTTP 402.
Compatibility API errors
Check the HTTP status first, then read the endpoint’s protocol error fields. Gateway rejections use the same error format as the model service. This section covers OpenAI Chat Completions / Responses, Anthropic Messages, and Gemini generation / Interactions. These endpoints use protocol-specific errors instead of LinkModel’s task API envelope.Covered endpoints and request schemas
Covered endpoints and request schemas
All paths below use
POST.- Chat Completions:
/v1/chat/completions - Responses:
/v1/responses - Responses Compact:
/v1/responses/compact - Messages:
/v1/messages - Gemini GenerateContent:
/v1beta/models/{model}:generateContent - Gemini StreamGenerateContent:
/v1beta/models/{model}:streamGenerateContent - Gemini Interactions:
/v1beta/interactions
body.code and body.msg with the protocol fields below. Use the HTTP status and machine-readable fields for decisions; use messages for display and diagnostics.
Error fields by protocol
error.code is not a universal integer code: its type depends on the protocol. Capture request identifiers from response headers or the body when present; a body-level request_id is not guaranteed.
Example: HTTP 401
- OpenAI
- Anthropic
- Gemini GenerateContent
- Gemini Interactions
Compatibility HTTP status codes
The following mappings apply to the compatibility endpoints listed above. For LinkModel task APIs, check the endpoint’s HTTP responses and businesscode together.
Upstream provider authentication or permission failures (
401, 403, or 407) are mapped to 502. A 401 returned to you indicates a problem with authentication at the LinkModel boundary, not a provider credential that you control.
Quota errors and rate limits
For the OpenAI-compatible Chat / Responses endpoints listed above:
Stop automatic retries for
insufficient_quota and resolve the balance or key limit. For a temporary rate limit, use bounded exponential backoff and honor Retry-After when provided.
For Anthropic-compatible endpoints, identify insufficient account balance by HTTP status 402: its body uses error.type: "invalid_request_error", which is also used for invalid requests. Do not classify this error by error.type alone.
Anthropic represents both kinds of 429 with error.type: "rate_limit_error". Gemini GenerateContent uses error.status: "RESOURCE_EXHAUSTED", and Interactions uses error.code: "rate_limit_exceeded" for 429. These fields alone cannot distinguish key quota exhaustion from a temporary rate limit; check your key limits and usage rather than retrying indefinitely or matching message text.
Streaming errors
For Gemini SSE generation, usePOST /v1beta/models/{model}:streamGenerateContent?alt=sse. The GenerateContent reference describes the separate :generateContent request with a JSON response; its response schema does not describe an SSE stream.
Once response headers have been sent, an SSE stream can remain HTTP 200 even if generation later fails. Handle both protocol error events and unexpected connection termination.
Parse complete SSE events: several
data: lines can belong to one event, terminated by a blank line. Do not treat each network chunk as a complete JSON object. A panic or broken connection after output starts can terminate the transport without a final error event. Preserve partial output as incomplete and do not treat EOF or HTTP 200 alone as success.
An interrupted or failed stream does not by itself prove zero usage or zero cost. Check usage records before retrying a request that may already have produced output.