Skip to main content
PUT
Provision (upsert) a subject
Idempotently provision an end-user partition. 201 on create, 200 after.

Authorization

This route requires the subjects:provision scope. A key carrying admin also qualifies. 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.

Notes

  • This is the provisioning call, and it is idempotent. 201 the first time, 200 afterwards, with the same body either way.
  • Provisioning is the privileged act, not selection. Creating a subject needs subjects:provision. Acting as one afterwards needs no extra scope: any read or write key in the organization can send X-Exo-Subject.
  • A subject id equal to an internal user id is refused with 409 conflict, so a developer-supplied id can never shadow a real member.

Authorizations

X-Exo-API-Key
string
header
required

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

Path Parameters

subject_id
string
required

Developer-supplied subject id: 1-128 chars of [A-Za-z0-9._:-].

Response

Successful Response

Public wire shape of a subject: {id, createdAt}.

id is the developer-supplied subject key (the selector value). The internal user id is deliberately NOT exposed: it is an isolation detail.

createdAt
string<date-time>
required
id
string
required