Skip to main content
This page explains common error responses for model calls and compatibility entry points. When troubleshooting, check both HTTP status and error.code: the status describes the protocol-level failure, while error.code identifies the platform-side failure reason written by the service.

Error Response Format

Relay APIs usually return an OpenAI-compatible error body:
Field reference:
Some non-relay management APIs use a top-level code, message, data, and dateTime response shape. For model relay, OpenAI-compatible, Claude-compatible, and Gemini-compatible entry points, use the error shape on this page first.

HTTP Status Codes

Platform Error Codes

These values come from the project’s types.ErrorCode definitions and fixed error codes written by the system performance guard.

Request And Parameters

Authentication, Access, And Quota

Model, Channel, And Routing

Upstream Request And Response

Safety

Data And System

Compatible Endpoint error.type

Some compatible endpoints do not return error.code and only mark the error category through error.type. Current video proxy endpoints use:

Retry Guidance

  1. 400, 401, 403, 404, and 413 usually require fixing the request, access, or quota first. Do not blindly retry them.
  2. 408, 429, 500, 502, and 503 can be retried with exponential backoff and a maximum retry count.
  3. sensitive_words_detected, prompt_blocked, and violation_fee.grok.csam require changing the input. Do not automatically retry the same request.
  4. insufficient_user_quota requires topping up or reducing model cost before sending another request.
  5. If message includes a request ID, include it when reporting the issue so logs can be located quickly.
Next, see Authentication for auth failures, or First Request Example for the minimal request format.

References