Skip to main content
PATCH
Update settings
Partially update the effective subject’s preferences. Only the provided fields change (upsert); an unknown field is rejected with a 422 validation problem. Free operation, not metered.

Authorization

This route requires the write scope. A missing or invalid credential returns 401 authentication_error. A valid credential without the scope returns 403 permission_denied, and the problem body names the exact scope required.

Headers

These are request conventions the contract does not declare as parameters, so they do not appear in the schema tables below.

Success responses

Errors

Every error is an RFC 9457 application/problem+json body carrying a stable code, a requestId, and a suggestedAction where Exo has one. See Errors.

Authorizations

X-Exo-API-Key
string
header
required

An Exo API key (exo_...) sent as the X-Exo-API-Key header.

Body

application/json

PATCH body: any provided field is upserted; omitted fields are unchanged.

extra="forbid" turns an unknown field (e.g. the descoped voiceMode or autonomyLevel) into a 422 validation_error rather than silently dropping it -- a write must never appear to succeed against a field the server cannot store. subject is the documented spec-4.2 selector; it is accepted here (and consumed by the resolve_subject seam) so a body-borne selector is not itself rejected as an unknown field.

learnModeDefault
boolean | null
qualityMode
enum<string> | null
Available options:
fast,
balanced,
thorough
subject
string | null

Response

Successful Response

The caller/subject's preferences (spec 4.9, honest M1 subset).

Only fields backed by a real, round-tripping user_settings column are present. qualityMode is documented as a string (not a closed enum) so a future stored mode never breaks a tolerant reader; on the wire today it is one of fast | balanced | thorough.

learnModeDefault
boolean
required
qualityMode
string
required