## Add members

`POST /v1/workgroups/:groupId/users`

Adds users to a workgroup right away, with no invitation and no confirmation on their side. Added users get the member role.

## Parameters

| Parameter | Type | Required | Description |
|-----------|------|:--------:|-------------|
| `groupId` (path) | number | yes | Workgroup ID — a positive integer. List: [`GET /v1/workgroups`](/docs/entities/workgroups/list) |

## Request fields (body)

| Field | Type | Required | Description |
|-------|------|:--------:|-------------|
| `userIds` | number[] | yes | Non-empty array of user IDs — positive integers. Strings such as `"93"` are not accepted. List: [`GET /v1/users`](/docs/entities/users/list) |

## Examples

### curl — personal key

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/workgroups/157/users" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"userIds": [93]}'
```

### curl — OAuth application

```bash
curl -X POST "https://vibecode.bitrix24.com/v1/workgroups/157/users" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"userIds": [93]}'
```

### JavaScript — personal key

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/workgroups/157/users', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ userIds: [93] }),
})

const body = await res.json()
if (!body.success && body.error.code === 'BITRIX_ERROR') {
  if (Array.isArray(body.error.processedUserIds)) {
    // Some users may already be added — changes are not rolled back
    console.log('Added:', body.error.processedUserIds)
    console.log('Not added:', body.error.skippedUserIds)
  } else {
    // The other 422: Bitrix24 refused the call, so the response has no arrays
    console.log('Bitrix24 refused:', body.error.message)
  }
}
```

### JavaScript — OAuth application

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/workgroups/157/users', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ userIds: [93] }),
})

const body = await res.json()
```

## Response fields

| Field | Type | Description |
|-------|------|-------------|
| `success` | boolean | `true` when all requested users are added |
| `data.groupId` | number | Workgroup ID |
| `data.processedUserIds` | number[] | IDs of the added users. Duplicates in `userIds` collapse into one |
| `data.skippedUserIds` | number[] | Always an empty array in a successful response. If not everyone could be added, the response is `422 BITRIX_ERROR` and both arrays move into `error`. That is the only response that carries them: the other `422 BITRIX_ERROR` — a refusal from Bitrix24 itself — carries only its own message in `error`, with no `processedUserIds` and no `skippedUserIds` |

## Response example

```json
{
  "success": true,
  "data": {
    "groupId": 157,
    "processedUserIds": [93],
    "skippedUserIds": []
  }
}
```

## Error response example

422 — the user is already in the group, so there is no one to add:

```json
{
  "success": false,
  "error": {
    "code": "BITRIX_ERROR",
    "message": "Bitrix24 did not change every requested user: existing membership or role, owner, scrum master, missing user or permissions may prevent the action. Do not blindly retry invitations.",
    "processedUserIds": [],
    "skippedUserIds": [93]
  }
}
```

## Errors

| HTTP | Code | Description |
|------|------|-------------|
| 400 | `INVALID_PARAMS` | `groupId` is not a positive integer, for example `15.7` |
| 400 | `MISSING_REQUIRED_FIELDS` | `userIds` is missing, empty or contains something other than positive integers |
| 401 | `MISSING_API_KEY` | `X-Api-Key` is not sent |
| 401 | `INVALID_API_KEY` | The key is not recognized — no such key exists on the platform |
| 401 | `TOKEN_MISSING` | The key has no Bitrix24 tokens |
| 403 | `SCOPE_DENIED` | The key lacks the `sonet_group` scope |
| 403 | `WRITE_BLOCKED_READONLY_KEY` | The key works in read-only mode |
| 403 | `BITRIX_ACCESS_DENIED` | The user the key acts on behalf of has no permission to change the membership of this group |
| 404 | `ENTITY_NOT_FOUND` | The group does not exist or is not visible to the user the key acts on behalf of |
| 422 | `BITRIX_ERROR` | Not all users were added. `error.processedUserIds` and `error.skippedUserIds` list who was added and who was not. A user is skipped if they are already in the group, have a pending invitation to it, or do not exist |
| 422 | `BITRIX_ERROR` | Bitrix24 refused the call and returned its own reason in `error.message`. This response carries no `error.processedUserIds` and no `error.skippedUserIds` — check that they are present before reading them, and re-read the membership before retrying |
| 429 | `RATE_LIMITED` | Request limit exceeded. Retry after the delay in the `Retry-After` header |
| 502 | `BITRIX_UNAVAILABLE` | Bitrix24 is unavailable or returned a response the endpoint cannot parse |
| 503 | `BITRIX_TIMEOUT` | Bitrix24 accepted the call but did not respond in time. The response includes a `Retry-After` header. Re-read the membership before retrying: the addition may have gone through |

Full list of common API errors — [Errors](/docs/errors).

## Known specifics

- **A partial result is not rolled back.** If `userIds` holds several users and some of them are skipped, the response is `422`, but the users in `error.processedUserIds` are already added. Before retrying, re-read the membership with [`GET /v1/workgroups/:groupId/users`](/docs/entities/workgroups/users) and send only the missing users.
- **An invited user cannot be added this way.** Until the invitation from [`POST /v1/workgroups/:groupId/invitations`](./invite.md) is accepted, the user lands in `skippedUserIds`. To add them right away, first cancel the invitation with [`DELETE /v1/workgroups/:groupId/users`](./remove.md).
- **Every addition shows up in the group chat.** For each added user, a system message announcing that they joined is posted to the group chat.
- **`422` does not name the reason for each skipped user.** A user who is already a member, a user with an unanswered invitation and a non-existent ID are skipped the same way. To find the reason, check the group membership and call [`GET /v1/users/:id`](/docs/entities/users/get).

## See also

- [Remove members](./remove.md)
- [Change member role](./role.md)
- [Invite members](./invite.md)
- [List workgroup members](/docs/entities/workgroups/users)
- [Workgroup members](/docs/workgroups/members)