/ Docs

Update Current User

Change the current user's own settings. A singular resource (the caller's own profile), so not collection-shaped.

PATCH
/v1/users/me

Authorization

BearerAuth
AuthorizationBearer <token>

Botyard API key — see /docs/authentication.

In: header

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

Changes to the signed-in user's own settings. Omitted fields are unchanged.

Response Body

application/json

curl -X PATCH "https://example.com/v1/users/me" \  -H "Content-Type: application/json" \  -d '{}'
{
  "user_id": "string",
  "email": "string",
  "name": "string",
  "avatar_url": "string",
  "created_at": "2019-08-24T14:15:22Z",
  "updated_at": "2019-08-24T14:15:22Z",
  "confirm_conversation_scope_changes": true,
  "share_usage_data": true
}
{
  "type": "string",
  "title": "string",
  "status": 0,
  "detail": "string",
  "instance": "string",
  "error_code": "string",
  "errors": [
    {
      "pointer": "string",
      "detail": "string",
      "type": "string"
    }
  ],
  "trace_id": "string"
}

Get Current User

Get the current authenticated user's profile.

Delete Current User

Delete the workspaces that go with the caller's account (PlatDev #4423). Called by the auth service's better-auth ``beforeDelete`` hook, after the person has re-authenticated and just before the login itself is deleted. Workspaces the caller is the only member of are deleted, through the same cascade as ``DELETE /v1/orgs/{id}``. Refused with 409 when the caller is the only owner of a workspace that has other members; then nothing changes and the auth service keeps the login. The caller's identity and memberships are left alone: the auth service's ``afterDelete`` strips and anonymizes them once the login is gone. Each workspace commits on its own, because ending its subscription is a billing-provider call no rollback can undo; if one fails, the ones before it stay deleted, the error is returned, the auth service keeps the login, and a retry carries on with what is left. Singleton by nature: it acts on the caller's own account only. Passing the guard records a deletion attempt for this request (PlatDev #4518), so a co-owner deleting concurrently no longer counts the caller as an owner. Every error path below deletes only this request's own attempt row before answering, never the caller's other attempts; the success answer keeps it, because the auth service deletes the login after it. The attempt id is returned in the ``Botyard-Account-Deletion-Attempt`` header so the auth service logs the same id (operator runbook).