For AI agents: markdown of this page — /docs-content-en/entities/users/me.md documentation index — /llms.txt

Current employee profile

GET /v1/users/me

Returns the profile of the employee the key acts on behalf of, plus a Bitrix24 account administrator flag with three states. The employee ID is not passed in the request.

Who the call runs as depends on the key type. A personal key vibe_api_ reads on behalf of its owner. An application authorization key vibe_app_ reads on behalf of the employee whose session token is sent in the Authorization: Bearer header.

Examples

curl — personal key

Terminal 
curl "https://vibecode.bitrix24.com/v1/users/me" \
  -H "X-Api-Key: YOUR_API_KEY"

curl — OAuth application

Terminal 
curl "https://vibecode.bitrix24.com/v1/users/me" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN"

JavaScript — personal key

javascript 
const res = await fetch('https://vibecode.bitrix24.com/v1/users/me', {
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
  },
})

const { success, data } = await res.json()

JavaScript — OAuth application

javascript 
const res = await fetch('https://vibecode.bitrix24.com/v1/users/me', {
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
  },
})

const { success, data } = await res.json()

Response fields

Field Type Description
Fieldsuccess Typeboolean DescriptionAlways true on success
Fielddata Typeobject DescriptionThe employee object under the same field names as in the GET /v1/users/:id response. The userType field is not part of this response. Full list — Employee fields
Fielddata.isAdmin Typeboolean · null DescriptionBitrix24 account administrator flag: true — administrator, false — not an administrator, null — could not be determined. The field is returned in this response only — it is not available in GET /v1/users/:id or in the employee list

Response example

Main fields are shown. Full list — Employee fields.

JSON 
{
  "success": true,
  "data": {
    "id": 29,
    "xmlId": "28936832",
    "active": true,
    "name": "John",
    "lastName": "Smith",
    "secondName": "Michael",
    "email": "john.smith@example.com",
    "lastLogin": "2026-03-30T14:39:25.000Z",
    "dateRegister": "2020-04-23T00:00:00.000Z",
    "timeZone": "Europe/Berlin",
    "isOnline": false,
    "timestampX": "03/30/2026 02:50:19 pm",
    "lastActivityDate": "2026-03-30 14:40:05",
    "personalGender": "M",
    "personalMobile": "+10000000000",
    "departmentId": [1],
    "UF_PHONE_INNER": "111",
    "isAdmin": true
  }
}

Error response example

403 — the key lacks the user scope:

JSON 
{
  "success": false,
  "error": {
    "code": "SCOPE_DENIED",
    "message": "This endpoint requires 'user' scope"
  }
}

Errors

HTTP Code Description
HTTP401 CodeTOKEN_MISSING DescriptionThe personal key has no configured Bitrix24 credentials
HTTP401 CodeTOKEN_MISSING DescriptionThe application authorization key was sent without the Authorization: Bearer header carrying a session token
HTTP403 CodeSCOPE_DENIED DescriptionThe key lacks the user scope
HTTP403 CodeBITRIX_ACCESS_DENIED DescriptionBitrix24 refused the call: the webhook or the session token lacks the user permission, or the employee has no access

Full list of common API errors — Errors.

Known specifics

Write the permission check as isAdmin === true, not !isAdmin. A null means the check could not be completed, and the profile still arrives in full with a successful response. The condition !isAdmin would read such a response as a lack of administrator rights that was never established. The flag cannot be forged in client code, so it is suitable for a permission check in your own backend.

The userType field does not arrive in this response. The account type — staff member employee or external user extranet — comes from GET /v1/users/:id. To confirm that the key acts as an active staff member, take id from this response and request GET /v1/users/:id with the same headers, then check that the response has active set to true and userType set to "employee". The set of UF_* user fields does not always match between the two responses either.

The timestampX and lastActivityDate fields arrive as strings in Bitrix24 formats, not as ISO 8601 — for example 03/30/2026 02:50:19 pm and 2026-03-30 14:40:05. The lastLogin and dateRegister fields arrive as ISO 8601. Do not pass the first two to a date parser that expects ISO.

The Bitrix24 account's user fields keep their UF_* names and arrive exactly as the Bitrix24 account returned them, without coercion to the declared field type.

See also