Responses API errors
POST /v1/responses returns errors in OpenAI’s Responses error
envelope. Errors that originate at Kindo’s edge use the table
below; errors that originate upstream are forwarded verbatim with
the upstream body and content-type.
Envelope
{ "error": { "message": "Model 'unknown-model' not found.", "type": "invalid_request_error", "code": "model_not_found" }}Status / type / code reference
| Status | Type | Common codes | Cause |
|---|---|---|---|
400 | invalid_request_error | invalid_body, model_not_found, unsupported_parameter | Body fails schema validation, references a missing model, or asks for a feature not yet implemented (e.g. previous_response_id). |
401 | — | — | Missing, malformed, or revoked API key. The body is a plain string envelope: {"error": "Unauthorized"}. |
403 | permission_error | model_access_denied | The key authenticated, but the user group does not grant access to the model. |
404 | not_found | — | E.g. GET /v1/responses/{id} for a response that does not exist or has been pruned. |
429 | rate_limit_error | — | Org or user rate limit exceeded. Honors the Retry-After header when present. |
500 | server_error | internal_error | Unexpected Kindo-side failure. |
502 | server_error | upstream_empty_body | Upstream LiteLLM / provider returned an empty response. |
401 exception
The 401 envelope is the plain-string form
{"error": "Unauthorized"} rather than the typed
{"error": {"message": "...", "type": "...", "code": "..."}} shape.
This matches how Kindo’s API-key middleware reports auth failures
across the Chat Completions and Responses APIs.
Mid-stream errors
If stream: true is set and an error occurs after the SSE has
started, Kindo emits an error event followed by response.failed:
event: errordata: {"error":{"message":"upstream stream interrupted","type":"server_error","code":"stream_error"}}
event: response.faileddata: {"id":"resp_abc123","status":"failed","object":"response"}The outer HTTP status stays 200 because headers were already
flushed when streaming began. SDK consumers should treat any
mid-stream error event as terminal.
See Streaming for the full SSE protocol.
Provider passthrough
When an upstream provider (Anthropic, OpenAI, etc.) returns a 4xx or
5xx with its own body, Kindo forwards that body verbatim, preserving
the upstream Content-Type. Your client sees whatever shape the
upstream produced — Kindo does not rewrap. The exception is
upstream_empty_body, which Kindo emits when the upstream returned
an HTTP error with no body so consumers always have a parseable JSON
envelope to log.
If you want a single consistent error shape across providers, parse on the outer HTTP status first; only fall back to body inspection when you need provider-specific detail.
See also
- Authentication —
401causes. - Model catalog —
403causes. - Streaming — mid-stream error events.
- Response store pruning —
404causes.