For AI agents: markdown of this page — /docs-content-en/chats/management/permissions.md documentation index — /llms.txt

Configure chat permissions

PUT /v1/chats/:dialogId/permissions/messages

PUT /v1/chats/:dialogId/permissions/guest-invites

PUT /v1/chats/:dialogId/permissions/settings

PUT /v1/chats/:dialogId/permissions/ui

PUT /v1/chats/:dialogId/permissions/users-add

PUT /v1/chats/:dialogId/permissions/users-delete

Six operations set who in a chat posts messages, invites guests, changes permissions, changes the chat's appearance, adds members and removes them. All six take the same body — the rightsLevel field.

Parameters

Parameter Type Required Description
dialogId (path) string yes Dialog ID: chatXXX for a group chat, a numeric user ID for private messages, me — the current user's personal dialog. A CRM entity chat is found via Find a CRM entity chat

The operations take no query parameters: any parameter in the query string is refused with 400 INVALID_PARAMS.

Request fields (body)

Field Type Required Description
rightsLevel string yes Who holds the permission: MEMBER — all members, MANAGER — managers and the owner, OWNER — the owner only, NONE — nobody. Case does not matter: manager and MANAGER are equivalent. Each operation has its own set of allowed values, listed in the table below

Other body fields are refused with 400 INVALID_PARAMS, and the message names the extra field.

What each operation sets, which values it accepts, and the value a group chat has right after it is created:

Operation Permission rightsLevel values In a new chat
permissions/messages Post messages and pin them MEMBER, MANAGER, OWNER, NONE MEMBER
permissions/guest-invites Invite guests MEMBER, MANAGER, OWNER, NONE MANAGER
permissions/settings Change chat permissions, the owner and managers MANAGER, OWNER OWNER
permissions/ui Change the name, description, color and avatar MEMBER, MANAGER, OWNER MEMBER
permissions/users-add Add members MEMBER, MANAGER, OWNER MEMBER
permissions/users-delete Remove members MEMBER, MANAGER, OWNER MANAGER

Examples

The examples let only the owner post to the chat. The other operations are called the same way — only the last path segment changes.

curl — personal key

Terminal 
curl -X PUT https://vibecode.bitrix24.com/v1/chats/chat2741/permissions/messages \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"rightsLevel": "OWNER"}'

curl — OAuth application

Terminal 
curl -X PUT https://vibecode.bitrix24.com/v1/chats/chat2741/permissions/messages \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"rightsLevel": "OWNER"}'

JavaScript — personal key

javascript 
const res = await fetch('https://vibecode.bitrix24.com/v1/chats/chat2741/permissions/messages', {
  method: 'PUT',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ rightsLevel: 'OWNER' }),
})

const { success } = await res.json()

JavaScript — OAuth application

javascript 
const res = await fetch('https://vibecode.bitrix24.com/v1/chats/chat2741/permissions/messages', {
  method: 'PUT',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ rightsLevel: 'OWNER' }),
})

const { success } = await res.json()

Response fields

Field Type Description
success boolean Always true on success
data boolean true — the permission is saved

Response example

JSON 
{
  "success": true,
  "data": true
}

Error response example

403 — the user on whose behalf the call is made is not a chat member:

JSON 
{
  "success": false,
  "error": {
    "code": "BITRIX_ACCESS_DENIED",
    "message": "ACCESS_DENIED"
  }
}

Errors

HTTP Code Description
400 INVALID_PARAMS The body has no rightsLevel or the value is not in this operation's set, for example NONE for permissions/settings, the body has another field, the body is not a JSON object, or the query string has a parameter. Checked before the Bitrix24 call
403 BITRIX_ACCESS_DENIED Bitrix24 refused: the user is not a chat member, or the settings permission does not let them change permissions
422 BITRIX_ERROR Bitrix24 returned an error; the portal code is in error.b24Code. If the chat does not exist, the code is CHAT_NOT_FOUND
403 SCOPE_DENIED The API key lacks the im scope
403 WRITE_BLOCKED_READONLY_KEY The key is read-only — changing permissions counts as a write
401 TOKEN_MISSING The API key has no configured Bitrix24 tokens
502 ME_ALIAS_RESOLUTION_FAILED dialogId=me — the current user's ID could not be resolved
502 BITRIX_UNAVAILABLE Bitrix24 is unavailable or returned a server error

Full list of common API errors — Errors.

Known specifics

A value outside the set is refused before the write. Bitrix24 would accept a value that is not in the operation's set, report success, and reset the permission to its default. So such a request is refused with 400 INVALID_PARAMS, and the permission stays as it was.

Current permissions. The permissions object of the Dialog details response has one field per operation, in the order of the table above: manageMessages, manageGuestInvites, manageSettings, manageUi, manageUsersAdd, manageUsersDelete. Their values are in lower case. The canPost field there repeats manageMessages.

See also