PATCH /api/v1/users/me/ updates your own first_name/last_name/ preferred_username/date_of_birth/ gender/phone_number and address fields — never status, organization, Role, or email/password, which go
through their own dedicated endpoints. These are the exact fields OIDC claims read (see Sign-in methods) —
an edit here is what an Application relying on this identity provider actually sees on
its next token.
avatar_url is read-only via the PATCH above — the only way to set it is a real
file upload:
POST /api/v1/users/me/avatar/
Content-Type: multipart/form-data
avatar: <file>JPEG, PNG, or WebP, 3MB or smaller. The upload is validated by actually decoding it
server-side — a renamed non-image file is rejected, not trusted because of its
extension or declared content type. The response's avatar_url is what appears in the picture OIDC claim on your very next token —
nothing downstream needed to change shape for this, only how the value gets set.
Registering a new passkey and signing in with one are covered on Sign-in methods. Once you have one, manage it from here:
GET /api/v1/passkeys/credentials/ -> your own passkeys, newest first
DELETE /api/v1/passkeys/credentials/{id}/ -> revoke oneThe list never includes the credential's own binary credential_id or public key — just a name, device type, whether it's backed up (synced across your
own devices by your platform's passkey manager), and when it was last used. Revoking is
a soft-delete: the credential immediately stops being offered by your device's passkey
picker on this Organization's sign-in page, and a real passkey_removed Audit log event is logged.