Skip to main content
POST
Reset settings
Restore the effective subject’s preferences to the server defaults (qualityMode ‘balanced’, learnModeDefault false) and return them. Naturally idempotent: resetting twice yields the same result. Only the fields this API exposes are reset; a profile display name is not touched. Free operation, recorded for audit.

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

Beyond the shared statuses, this route can answer with idempotency_in_flight, idempotency_key_reuse. Every problem body names its own code, and the type URI always resolves to the matching page. 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

POST /v1/settings/reset body. Optional; the only field is the selector.

extra="forbid" keeps the call honest in the other direction too: a body like {"qualityMode": "fast"} is a 422 rather than a silently ignored field, because reset takes no values -- it restores the server defaults.

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