request_id and troubleshooting
Use request_id to trace call failures and upstream errors.
Keep request_id when you hit a problem
The gateway attempts to include X-Request-Id in the response headers. OpenAI- and Gemini-style error bodies also return request_id; for Anthropic-style errors, check the response header.
Where to find it
Prop
Type
Error response examples
{
"error": {
"message": "missing API key",
"type": "authentication_error",
"code": "api_key_missing",
"request_id": "req_..."
},
"request_id": "req_..."
}{
"type": "error",
"error": {
"type": "authentication_error",
"message": "missing API key",
"code": "api_key_missing"
}
}{
"error": {
"code": 401,
"message": "missing API key",
"status": "UNAUTHENTICATED"
},
"request_id": "req_..."
}Troubleshooting order
Record request_id first
Copy the X-Request-Id response header instead of taking only a screenshot of the error message.
Check the protocol error fields next
For OpenAI / Anthropic, check string error codes such as api_key_missing, insufficient_balance, and model_not_found; for Gemini, check error.status and error.message. If usage_missing or usage_invalid appears, the response did not provide valid usage or meet the conditions for a safe estimate.
Compare with the protocol page last
Confirm that the headers, path, public model id, and streaming method belong to the current API family or entry.
request_id is not a secret
You can use request_id when coordinating troubleshooting. Do not expose user API keys, upstream provider keys, or other secrets in screenshots, logs, or issues.
Last updated on