Get user by ID
AuthorizationBearer <token>Scope: user.read
user_id*string^user_[a-zA-Z0-9_-]+$team_id?stringServes the user only when they hold an active membership in this team,
and answers 404 otherwise.
This is team membership, not lifecycle ownership: it asks which team
the user collaborates in, not which team may deprovision them. The
owning team is reported separately as
metadata.lifecycle_owner_team_id, and a user can belong to many teams
while owning their own lifecycle. See ADR 024.
Only active memberships match. A user who has been invited but has not accepted is not served.
It reads the user's memberships, so it takes the same permission as the
team_id filter on POST /users/query: team_membership.read for a
project secret, read on the whole project for a Console session.
Otherwise the answer is 403 user.permission_denied.
^[a-zA-Z0-9_-]+$Current user information retrieved successfully
application/json- response
A user represents an individual identity in the system. It can be used to represent a human user, but also a service account or any other type of identity.
attributes is the document that satisfies the user schema named by
schema: its property names and types are defined entirely by that schema,
and it is what the schema validates. The rest of the object — id,
schema, metadata — is the server-owned envelope. Keeping the two apart
means a schema may name a property id or metadata without colliding with
the envelope, and closed-world keywords (additionalProperties: false,
propertyNames, unevaluatedProperties) behave as their author expects.
id*user-id^user_[a-zA-Z0-9_-]+$schema*stringThe schema that defines the content of attributes. These schemas can be
created using the /schemas endpoint. A default schema is provided.
This schema can be retrieved using the same endpoint.
attributes*The user's content, satisfying the schema named by schema. Property
names and types are determined entirely by that schema.
metadata*identifier?stringThe current value of the user schema's designated identifier
(x-identifier), resolved live at read time. Absent when the schema
designates no identifier or the user carries no value for it.
identifier_property?stringThe schema property identifier came from, so clients can reach the
property's schema for semantics (a mailto link, a field label)
instead of guessing from the value. Present exactly when
identifier is.
display?stringThe x-display rendering — the designated properties' values joined
in list order, resolved live at read time. Purely presentational.
Absent when the schema designates no display properties or the user
carries no values for them. Clients render display, falling back
to identifier, then id.
teams?array<>The user's team memberships, present only when the request asked for them with
expand: ["teams"] (ADR 059). Absent means it was not requested; []
means the user has none.
Deliberately outside metadata: memberships are a related collection, not
part of the server-owned envelope, and it is a different concept from
metadata.lifecycle_owner_team_id (ADR 024).
teams_truncated?booleanTrue when the user is on more teams than the embedded list carries. The
embedded list is capped and cannot be paged; read them all at
GET /users/{user_id}/teams. Present only alongside teams.
curl -X GET 'https://example.com/users/string'{ "id": "string", "schema": "string", "attributes": {}, "metadata": { "created_at": "2019-08-24T14:15:22Z", "updated_at": "2019-08-24T14:15:22Z", "status": "active", "lifecycle_owner_team_id": "string", "lifecycle_owner_team": { "id": "string", "name": "string", "status": "active", "created_at": "2019-08-24T14:15:22Z", "updated_at": "2019-08-24T14:15:22Z" } }, "identifier": "string", "identifier_property": "string", "display": "string", "teams": [ { "id": "string", "name": "string", "membership_status": "pending", "created_at": "2019-08-24T14:15:22Z", "updated_at": "2019-08-24T14:15:22Z" } ], "teams_truncated": true}