## Current user profile

`GET /v1/users/me`

Returns the profile of the employee the key acts as, plus a portal-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 as its own owner. An application authorization key `vibe_app_` reads as the employee whose session token is sent in the `Authorization: Bearer` header.

## Examples

### curl — personal key

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

### curl — OAuth application

```bash
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 |
|------|-----|---------|
| `success` | boolean | Always `true` on success |
| `data` | object | The employee object under the same field names as in the [`GET /v1/users/:id`](/docs/entities/users/get) response. Full list — [Employee fields](/docs/entities/users/fields) |
| `data.isAdmin` | boolean · null | Bitrix24 account administrator flag: `true` — administrator, `false` — not an administrator, `null` — could not be determined. The field arrives in this response only, on `GET /v1/users/:id` and in the employee list it is unavailable |

## Response example

Main fields are shown. Full list — [Employee fields](/docs/entities/users/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 |
|------|-----|---------|
| 401 | `TOKEN_MISSING` | The personal key has no configured Bitrix24 credentials |
| 401 | `TOKEN_MISSING` | The application authorization key was sent without the `Authorization: Bearer` header carrying a session token |
| 403 | `SCOPE_DENIED` | The key lacks the `user` scope |
| 403 | `BITRIX_ACCESS_DENIED` | Bitrix24 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](/docs/errors).

## Known specifics

**Write the rights 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 rights check in your own backend.

**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.

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

## See also

- [Get employee](/docs/entities/users/get)
- [Employee fields](/docs/entities/users/fields)
- [List employees](/docs/entities/users/list)
- [Key self-description](/docs/keys-auth/me)