Skip to main content

Handle errors in code

The SDKs raise a typed error on any non-2xx response, with status_code / statusCode and the parsed body.

Session failures

A settled session reports two signals on status, the session object, and changes, so your code can branch without parsing prose.

Outcomes

A session can end completed and still not do what you asked. outcome is the agent’s own assessment, reported with its final answer: outcome is a self-assessment, not verified ground truth: validate the answer itself for high-stakes flows. It is null when the agent ended without reporting one.

Error codes

When a session ends failed or timed_out, it carries an error_code and an error message matching it:
  • error_code is null unless the status is failed or timed_out.
  • New codes may appear: treat unknown values like internal.
  • Branch on error_code, log error.

HTTP status codes

Client error codes

Quota errors (429)

A session 429 says which limit was hit in detail[].type, and whose slots ran out in detail[].scope:
Quota error (429)
In the local runtime, its session cap answers capacity with scope platform.

Server error codes

Error envelope

Every error response carries the same envelope: a message that summarizes the problem, and a detail array with one entry per problem. For 422 validation errors, each detail entry keeps the failing field’s path and reason, and message flattens them into one line:
Validation error (422)
Requests rejected before they reach the API (for example 401) may carry only a message. Vault, browser profile and session file endpoints are the exception: apart from 422 validation errors, most of their errors carry a single detail string and no message:
Vault not found (404)