HTTP-level errors
These are returned by the API before any SSE event is emitted. The response body is typically a JSON object with adetail field (for validation errors) or a plain
error message. Your HTTP client should check the response status before consuming
the stream.
| Status | Cause | Recommended action |
|---|---|---|
400 | Malformed request body or invalid field value. | Fix the request payload. The response body usually identifies the offending field via the validation loc array. Do not retry as-is. |
401 | Missing or invalid API key. | Verify the X-API-Key header. Do not retry until the credential is rotated or restored. |
403 | The API key is valid but not entitled to this resource (model tier, template, or feature). | Surface the entitlement message; ask the user to upgrade or grant access. Do not retry. |
404 | Resource not found. Common when from_checkpoint_id, chat_id, or a workflow template_id does not exist or has been deleted. | Validate the identifier; reset and create a new conversation if appropriate. |
422 | Request body failed schema validation. | Inspect detail[].loc and detail[].msg; correct the payload. |
429 | Rate limit exceeded. | Back off and retry. See Retry and backoff below. |
5xx | Transient server-side failure. | Retry with backoff; alert if persistent. |
response.raise_for_status() (in Python’s requests)
to convert HTTP errors into exceptions before entering the streaming loop. Trying
to consume the SSE stream from a non-2xx response will silently produce zero events.
Stream-level errors
Once the HTTP response is established with a 2xx status, errors are delivered as typed messages inside the stream. Three message types matter:| Type | Severity | Effect on stream | Recommended action |
|---|---|---|---|
LLM_RETRY | Informational | Continues. Agent retries internally. | Log if useful; otherwise ignore. No user-facing impact. |
TOOL_ERROR | Recoverable | Continues. Agent may try a different tool or proceed without that source. | Log with tool_name. Do not raise. Surface to the user only if the final answer is materially degraded. |
ERROR | Fatal | Terminates. No COMPLETE event will follow. | Surface to the user. Abort the stream consumer. Log with full context. |
LLM_RETRY
The agent’s upstream LLM call hit a transient failure (rate limit, timeout,
short-lived error) and is being retried automatically. The stream will resume
without further action.
TOOL_ERROR
A specific tool failed. The tool_name field identifies which one. The agent will
continue, possibly calling a different tool or synthesizing without that source.
Most integrations log these events and only surface a user-visible warning if the
final answer is materially degraded (for example, if every search call failed).
ERROR
The request cannot continue. The stream terminates immediately after this event;
no COMPLETE will follow. Surface the error to the user and stop reading the
stream.
error field is a human-readable string suitable for logging, but not always
suitable for direct display to end users. Wrap it in your own UX-friendly message
where appropriate.
Worked example: error-aware streaming handler
The handler below distinguishes HTTP-level failures, stream-level errors, and informational retries. It logs per-event details and only raises when the request can no longer succeed.- Pre-stream HTTP errors — raised immediately so callers do not waste cycles reading an empty stream.
- In-stream recoverable events — logged at appropriate levels but never raised.
- In-stream fatal events — raised so callers can surface the failure.
- Truncated streams — detected by the absence of a
COMPLETEevent, preventing silent “empty answer” bugs.
Retry and backoff
For429 and 5xx HTTP responses, exponential backoff with jitter is the safe
default:
400, 401, 403, or 404: those reflect client-side or
identity problems that will not resolve on retry.
In-stream events do not benefit from retry at the request level. LLM_RETRY and
TOOL_ERROR already represent the agent’s own internal retry behavior; the
request is doing the right thing without your help.
When to abort versus continue
| Situation | Abort | Continue |
|---|---|---|
HTTP 400 / 401 / 403 / 404 | Yes; fix and re-issue. | — |
HTTP 429 | Yes; back off, then retry. | — |
HTTP 5xx | Yes; back off, then retry. | — |
ERROR message | Yes; stream is over. | — |
LLM_RETRY message | — | Yes; the agent is recovering. |
TOOL_ERROR message | — | Yes; the agent may compensate. Tally counts for end-of-stream UX. |
Truncated stream (no COMPLETE) | Yes; the response is incomplete. | — |
Malformed data: line (JSONDecodeError) | — | Yes; skip the line only, not the stream. |
Next steps
Streaming responses
Full reference for every message type the stream may emit.
Conversation continuity
Recover from a 404 on
from_checkpoint_id by resetting the thread.