API changes: September 30, 2026

← Changelog · September 2026

NEW-0930-1: Chats: messenger settings and v2 service methods

The chats section gained messenger settings and service methods on the Bitrix24 messenger v2 methods. GET /v1/chats/settings reads the user's general settings, PATCH on the same address changes one setting, and PUT /v1/chats/settings/status sets the status — online, dnd or away. Without userId the operations work with the key owner's settings; another user's settings are open to a Bitrix24 administrator only. GET /v1/chats/:dialogId/task-form and POST /v1/chats/messages/:messageId/task-form return the task creation form data for a chat and for a message, and GET /v1/chats/:dialogId/flow-form the flow form data of a collab. POST /v1/chats/:dialogId/bot-context hands a context to the chat's bots, and POST /v1/chats/:dialogId/zoom creates a Zoom meeting and posts the invitation to the chat. GET /v1/chats/state returns the update state and counters, GET /v1/chats/tariff-restrictions the plan restrictions, GET /v1/chats/promotions the active promo hints, and GET /v1/chats/users/:userId/department the user's department. POST /v1/chats/desktop/logout marks the desktop app offline. The task and flow forms can make the caller a chat member, as opening the chat does. Reading the update state marks the user online, and reading general settings may create a settings-preset binding. A read-only key therefore gets 403 WRITE_BLOCKED_READONLY_KEY on these GET routes and on the other changing operations. An unknown or repeated parameter is refused with 400 INVALID_PARAMS, and the Bitrix24 refusal code arrives in error.b24Code.

NEW-0930-2: Chats: the unread mark, read later, mentions, the membership check and chat folders

The chats section gained seven endpoints on the Bitrix24 messenger v2 methods. POST and DELETE /v1/chats/:dialogId/unread set and clear the "unread" mark on the chat's row in the recent dialog list, and POST /v1/chats/messages/:messageId/mark marks the message the chat opens at next time — "read later"; the same DELETE clears it. GET /v1/chats/:dialogId/users/mentionable returns the chat members who can be mentioned with @, and GET /v1/chats/:dialogId/users/membership checks which of the given users are chat members. GET /v1/chats/folders returns the user's chat folders — the messenger's system sections and personal folders, and GET /v1/chats/folders/:folderId/recent returns the chat list of one folder in pages by the lastMessageDate cursor. An unknown or repeated parameter is refused with 400 INVALID_PARAMS, and the Bitrix24 refusal code arrives in error.b24Code. The mark and read later remain modifying calls and receive 403 WRITE_BLOCKED_READONLY_KEY with a read-only key. Mentions and the membership check are available to an ordinary employee personal key only for an existing chat under the access rights contract; they may make the user a member when the chat allows auto-join; GET /v1/chats/folders is also blocked: the Bitrix24 account may initialize folders and migrate pins; listing chats in an existing folder remains a read.

NEW-0930-3: Chats: files and CoPilot on the messenger v2 methods

POST /v1/chats/:chatId/files with the format=v2 parameter uploads a file and publishes the message in one messenger v2 call and answers 200 with the file entity, messageId, chatId and dialogId. Without format=v2 the upload responds as before. New endpoints: POST /v1/chats/files/save copies chat files to the user's Drive, POST /v1/chats/files/:fileId/transcribe starts the transcription of an audio or video file. The CoPilot section opens the CoPilot draft chat (POST /v1/chats/copilot/draft), switches the assistant's model and role (PUT /v1/chats/:dialogId/copilot/engine, PUT /v1/chats/:dialogId/copilot/role), asks it to regenerate an answer (POST /v1/chats/messages/:messageId/regenerate) and rates the answer (POST /v1/chats/messages/:messageId/vote). All new operations are writes: a read-only key gets 403 WRITE_BLOCKED_READONLY_KEY. An unknown, missing or invalid body field is refused with 400 INVALID_PARAMS before any call to Bitrix24, and the Bitrix24 refusal code arrives in error.b24Code. File links in the responses of these operations open only in the user's own Bitrix24 session and carry no Bitrix24 account credentials.

FIX-0930-4: legacy file metadata for an ordinary key

GET /v1/chats/files/:fileId again requires only im and returns downloadUrl for an ordinary key, as in main bd93898fc422, reversing the corresponding !4345 BC change. READONLY retains the additional disk requirement and receives no download link.

POST /v1/chats/:chatId/files without format=v2 again uses the original three steps and retries as in main bd93898fc422, returns downloadUrl, adds no 502 for commit=false, and makes no disk.file.delete call. The associated queue and scope-repair retry opt-outs are removed; the READONLY write refusal remains.

GET /v1/chats/:chatId/folder again forwards raw query parameters for an ordinary key as in main bd93898fc422. The READONLY refusal of potential folder initialization remains.

NEW-0930-5: Chats: members on messenger v2 — managers, members as entities, active members and membership records

The chat members section gained operations on the Bitrix24 messenger v2 methods. Three new endpoints manage chat managers: POST /v1/chats/:dialogId/managers assigns managers, PUT /v1/chats/:dialogId/managers replaces their whole list, and DELETE /v1/chats/:dialogId/managers removes the role. GET /v1/chats/:dialogId/member-entities returns the chat members as "type — ID" pairs together with linked departments, GET /v1/chats/:dialogId/users/active returns members in the chosen sort order, for example the most active ones, and GET /v1/chats/:dialogId/users/relations returns the roles of the named users in the chat. The format=v2 parameter arrived on four existing endpoints: GET /v1/chats/:dialogId/users returns members with their roles in pages by a cursor, POST /v1/chats/:chatId/users and DELETE /v1/chats/:chatId/users add and remove members, and POST /v1/chats/:chatId/owner transfers ownership — and only to a chat member. Without format=v2 all four respond as before. On the new endpoints and in the v2 mode an unknown or repeated parameter is refused with 400 INVALID_PARAMS, and the Bitrix24 refusal code arrives in error.b24Code for 422 and 404 responses. The reads of the new endpoints and the v2 member list may make the user a chat member when the chat allows auto-join, so they count as writes: a read-only key gets 403 WRITE_BLOCKED_READONLY_KEY for them, as described on the access rights page.

FIX-0930-6: restore legacy member-list parameters for ordinary keys

GET /v1/chats/{dialogId}/users again forwards additional raw query parameters for ordinary keys as main did before stage 2. Parameter filtering remains only for READONLY keys; the format=v2 mode is unchanged.

FIX-0930-7: restore chat owner body forwarding

POST /v1/chats/{chatId}/owner again forwards additional body fields of an ordinary key to the Bitrix24 account as main did before stage 2. The checked CHAT_ID and USER_ID still take precedence. A READONLY key is refused before the Bitrix24 call; the format=v2 mode is unchanged.

NEW-0930-8: Chats: messenger v2 — deletion, joining, the parent chat, the access check and v2 modes of the chat card, creation and update

The chats section gained seven endpoints on the Bitrix24 messenger v2 methods. DELETE /v1/chats/:dialogId deletes a group chat for all members together with its messages and files — irreversibly; the response arrives before the actual deletion. POST /v1/chats/:dialogId/join joins an open chat, PUT and DELETE /v1/chats/:dialogId/parent attach a chat to a parent chat and detach it, GET /v1/chats/access checks access to a chat or a message, POST /v1/chats/dialog-id returns the dialog ID for a user ID, a CRM entity or a workgroup and creates the chat when there is none yet, and GET /v1/chats/messages/:messageId/load opens a chat around the given message. Four existing endpoints gained modes: format=v2 on the dialog card, on chat creation and on chat renaming — the latter changes the chat as a whole in this mode: the description, avatar, owner, permissions, members and managers — and shallow=true on chat loading — the card, members and context without the page of messages. Without the parameter these endpoints respond as before. Body fields are checked before any call to Bitrix24: an unknown field or a value outside the list is refused with 400 INVALID_PARAMS. The v2 card, the lightweight load, the access check and loading around a message may make the user a chat member when the chat allows auto-join, so a read-only key gets 403 WRITE_BLOCKED_READONLY_KEY for them, as for all the new modifying endpoints — see access rights.

FIX-0930-9: legacy chat creation for an ordinary key

POST /v1/chats without format=v2 again forwards users and raw legacy parameters to Bitrix24 without the new 400 INVALID_PARAMS, as in main bd93898fc422. This restores the ordinary behavior changed by the !4345 BC fragment. The READONLY write refusal and the v2 draft mode remain.

PATCH /v1/chats/:chatId again continues renaming after a temporary membership-check failure, as in main bd93898fc422: no MembershipProbeGuard, new 503, or probe limit. A confirmed access refusal still returns 404.

GET /v1/chats/:dialogId again forwards raw query parameters for an ordinary key, as in main bd93898fc422; READONLY retains the path dialog binding.

POST /v1/chats/:chatId/leave again forwards raw body fields to Bitrix24 for an ordinary key, as in main bd93898fc422. The READONLY write refusal remains.

NEW-0930-10: Upload and delete catalog product images

POST /v1/catalog-products/:productId/images uploads an image. DELETE /v1/catalog-products/:productId/images/:imageId deletes it. Upload responses contain safe metadata without webhook credential URLs.

BC-0930-11: Apps return their original redirects to the client

Old format supported until: not provided

Before

When an app responded with a redirect, the platform followed Location itself. The client received the final response instead of the original 3xx, and cookies from the first response were lost.

After

Black Hole apps return the original 301, 302, 303, 307, or 308, Location, and ordinary cookies under the existing rules. When opening an app's public address, an absolute Location pointing to its exact internal address is replaced with its public address. External and relative addresses are unchanged. Platform cookie policy and special /robots.txt responses are preserved.

What integrators should do

If your HTTP client relied on the platform to follow redirects, handle 3xx and follow Location on the client with an appropriate security policy. For your own OAuth flow, explicitly configure a public callback URL: a nested redirect_uri is not rewritten. Service calls through the app external API do not receive absolute-address rewriting or response cookies.

NEW-0930-12: Notifications: messenger v2 — marking by list, marking all, deleting all, groups and delivery settings

The notifications section gained operations on the Bitrix24 messenger v2 methods. POST /v1/notifications/read with the format=v2 parameter marks exactly the named notifications as read — body { "ids": [...] }, up to 100 ids, response { counter, viewedMessages }; without format=v2 the endpoint responds as before. POST /v1/notifications/read-all marks every notification as read except those listed in excludeIds. DELETE /v1/notifications irreversibly deletes all notifications of the key owner and accepts the bare address only: any query parameter or body field is refused with 400 INVALID_PARAMS. Notification groups are read, created, renamed and deleted through /v1/notifications/groups, group conditions through /v1/notifications/groups/:groupId/conditions; removing the last condition deletes the group too. GET /v1/notifications/settings returns the delivery settings per channel, PATCH turns one channel of an event on or off, and PUT /v1/notifications/settings/scheme switches the settings mode; switching to the simple mode rewrites the settings of individual events, and switching back to the advanced mode does not restore them. An unknown, repeated or malformed parameter is refused with 400 INVALID_PARAMS before any Bitrix24 call, and the Bitrix24 refusal code arrives in error.b24Code for 422 and 404 responses. Reading groups and settings is open to a read-only key; the other operations answer it with 403 WRITE_BLOCKED_READONLY_KEY.

NEW-0930-13: Bitrix24 account web search settings — advanced mode and a daily spend cap

A Bitrix24 account admin can turn off the advanced mode and set a daily spend cap for paid search. The settings apply to search through the platform engine. Searches on your own provider key are not affected.

When the advanced mode is off, POST /v1/search with search_depth: "advanced" runs in basic mode, and the request is not rejected. The response and the SSE start and done events carry search_depth: "basic", the charge is the basic price, and the response headers include X-Search-Depth-Downgraded: advanced.

When the paid search spend of the Bitrix24 account for the current day in Moscow time reaches the cap, POST /v1/search and POST /v1/research return 429 SEARCH_DAILY_CAP_REACHED with a Retry-After header and a resetAt field pointing to the start of the next day. For Bitrix24 accounts without these settings nothing changes.

FIX-0930-14: `/v1/oauth/authorize` rejects `state` prefixed with `open-app:`

Before

Any state value was stored as is.

After

A state starting with open-app: gets 400 INVALID_REQUEST: the prefix is reserved for the internal catalog open-app flow.

FIX-0930-15: an immediate bot event re-poll after an error no longer gets 409

Before

GET /v1/bots/:botId/events returned a Bitrix24 error (for example, 403 BITRIX_ACCESS_DENIED) before the poll for that bot was considered finished. An immediate re-poll could get 409 BOT_EVENTS_BUSY even though the first poll had already answered.

After

The error is returned only after the poll finishes, so the next poll immediately gets its own response. Error codes and statuses are unchanged, and the HTTP 200 response is unchanged too.

BC-0930-16: POST aggregate rejects legacy-format fields outside the array

Old format supported until: not provided

Before

POST /v1/<entity>/aggregate accepted a body such as { "op": "sum", "field": "amount" }, ignored the requested operation, and returned HTTP 200 with the record count.

After

Such a request returns HTTP 400 INVALID_PARAMS with an example of the correct aggregate array. On routes where an empty body or the supplied filter already met the entity-specific requirements, those bodies still request the record count.

What integrators should do

Pass expressions in the array: { "aggregate": [{ "field": "amount", "function": "sum" }] }.

FIX-0930-17: key button on an empty slot in the application list

Before

In GET /v1/applications, a card with an empty personal slot kept key.rotatable at false and key.rotateBlockedReason at ISSUANCE_BLOCKED when the Bitrix24 account had no commercial tariff. A holder of a paid Cowork seat saw the same answer as a Bitrix24 account with no right to a key.

After

For that holder, key.rotatable becomes true and key.rotateBlockedReason becomes null. The list response remains HTTP 200. Quota, disabled infrastructure and a read-only policy still turn the button off.

FIX-0930-18: a busy server no longer points the machine field at a call that refuses

Before

On a 409 EXEC_BUSY for a server with kind: STANDALONE, error.hint.recoveryAction was always POST /v1/infra/servers/:id/unstick. That included the response that already names a live holder in error.hint.holder, or shows the lock has not expired yet (error.hint.autoExpiresInSeconds greater than zero). Calling that endpoint without force in that state answers 409 OPERATION_IN_PROGRESS.

After

When the response carries error.hint.holder, or error.hint.autoExpiresInSeconds is greater than zero, error.hint.recoveryAction is a wait directive: wait for the named operation to finish, then retry the same call. The field contains no endpoint. POST /v1/infra/servers/:id/unstick stays in the field only when the holder is absent and autoExpiresInSeconds is zero. The refusal itself is unchanged: it is still 409 EXEC_BUSY with retryable: true and a Retry-After header. The error.hint.recovery text is unchanged.

FIX-0930-19: post-not-found responses and post id and recipient refusals return an English message

Before

PATCH /v1/posts/{id}, DELETE /v1/posts/{id} and POST /v1/posts/{id}/share returned the Bitrix24 account's text as is in error.message when Bitrix24 refused with 404 POST_NOT_FOUND, 400 INVALID_POST_ID or 400 INVALID_RECIPIENTS. POST /v1/posts/{id}/comments and DELETE /v1/posts/{id}/comments/{commentId} did the same for a 404 POST_NOT_FOUND refusal. On a Russian-language account that text was in Russian.

After

error.message of such responses is a fixed English text. For 404 POST_NOT_FOUND it is Post <id> not found or not accessible with this key., and for DELETE /v1/posts/{id}/comments/{commentId} it is Post or comment not found or not accessible with this key., because that response does not state which of the two — the post or the comment — was not found. For 400 INVALID_POST_ID — Bitrix24 rejected the post id., for 400 INVALID_RECIPIENTS — Bitrix24 rejected one or more recipients. Codes and statuses are unchanged.

Impact on integrators

Client code that branches on error.code needs no change. Parsing the error.message text of these responses is no longer needed.

NEW-0930-20: Chats: messages on the messenger v2 methods — the first page, views, disappearing messages and read marks

The chats section gained six new endpoints on the Bitrix24 messenger v2 methods. GET /v1/chats/:dialogId/messages/initial returns the first page of a chat — around the unread mark or the last read message, and GET /v1/chats/messages/:messageId/viewers returns who viewed a message and when, in pages by the lastId cursor. POST /v1/chats/messages/:messageId/disappear sets a deletion timer on a message, POST /v1/chats/messages/:messageId/inform delivers it to a recipient in Do Not Disturb as an important notification, DELETE /v1/chats/messages/:messageId/url-preview removes a link preview, and POST /v1/chats/messages/read marks the selected messages as read — from 1 to 100 per request. Sending, editing, deleting and marking a chat as read gained the format=v2 mode: an edit changes the attachments, keyboard, menu and blocks as well as the text, and an edit or a deletion checks that the message belongs to the dialog in the path, answering 404 ENTITY_NOT_FOUND and changing nothing otherwise. Without format=v2 these endpoints respond as before. Invalid input is refused with 400 INVALID_PARAMS before any call to Bitrix24, and the Bitrix24 refusal code arrives in error.b24Code. The first page and the views may make the user a member of a chat that allows auto-join, so a read-only key gets 403 WRITE_BLOCKED_READONLY_KEY for them, as described on the access rights page.

FIX-0930-21: restore partial legacy message batch results

POST /v1/chats/messages/bulk again preserves the pre-stage-2 handling of duplicates, value types and partial HTTP 200 outcomes. The new local 400 refusals and complete-outcome requirement returning 502 are removed. Central READONLY admission remains conditional on the key.

FIX-0930-22: restore the existing legacy message mutations

Legacy PATCH and DELETE again send the Bitrix24 command without an extra dialog-membership lookup or the new 404/503 refusals. The READONLY check precedes writes. The format=v2 mode retains its separate contract.

FIX-0930-23: restore legacy feed parameters for ordinary keys

GET /v1/chats/{dialogId}/messages again forwards additional raw parameters for ordinary keys as main did before stage 2. Selector and pagination filtering remains only for READONLY keys; the format=v2 mode is unchanged.

FIX-0930-24: restore legacy read-mark input handling

Legacy POST /v1/chats/{dialogId}/read again omits an unusable messageId instead of returning the new 400 refusal and preserves the pre-stage-2 dialog ID dispatch. READONLY keys still fail before writes. The format=v2 mode is unchanged.

FIX-0930-25: restore legacy message-send fields

Legacy POST /v1/chats/{dialogId}/messages again forwards additional body fields for ordinary keys to Bitrix24 alongside the canonical DIALOG_ID and MESSAGE, as main did before stage 2. READONLY checks remain in place.

FIX-0930-26: block message viewers for read-only keys

GET /v1/chats/messages/{messageId}/viewers may add the caller to the chat. READONLY and PORTAL_READONLY keys now receive 403 WRITE_BLOCKED_READONLY_KEY before Bitrix24 is called.

FIX-0930-27: speech recognition with a disabled model now answers 404 before recognition

Before

POST /v1/audio/transcriptions with a model that is disabled or missing from the platform catalog sent the request to the recognition service when it was the default model — including requests without the model field. The service refused, and the response was 502 ai_provider_unavailable asking to try again later. Retrying did not help.

After

A model without an enabled catalog entry — including the default model when model is omitted — is rejected with 404 ai_model_not_found before recognition; nothing is charged. POST /v1/embeddings answers a disabled model the same way. Transcription is not available on the international platform yet, so every transcription request there, the default model included, is rejected this way.

BC-0930-28: cancelling a Cowork order reverses the seat purchase in the revenue export, and three amounts become signed

Old format supported until: not provided

Before

Charge amounts in the revenue export always came positive. When Bitrix24 cancelled a paid Cowork order, GET /v1/platform/revenue/refunds counted the vibes the receipt had already spent on seats as really consumed: they landed in consumedRealVibes, even though the seats of a cancelled order are removed and the money goes back to the buyer.

After

The first revoke of a receipt of such an order unwinds the seat purchase, and the export shows it differently depending on whose vibes paid for the seats.

• The part of the cost paid with the vibes of this order's own receipts is reversed by a negative movement in the same window: in chargedInPeriod of GET /v1/platform/revenue/charges (plus one event in chargeEventCount) and in consumedVibes under COWORK_SUBSCRIPTION of GET /v1/platform/revenue/consumption/by-service and GET /v1/platform/revenue/consumption/reconstructed. /refunds revokes the receipt in full, so consumedRealVibes no longer contains that part. The window total per tranche usually stays non-negative; with a partial cancellation, when the reversal and the revoke fall into different windows, the window's row can be negative.
• The part paid with the Bitrix24 account's earlier vibes (the seat charge takes the oldest balances first) comes back as a new tranche, the same way as a seat-cancellation refund: GET /v1/platform/revenue/credits shows it with kind = refund, while the seat purchase stays consumption in /charges, /consumption/by-service and /spend.

The reconciliation consumedLifetime = consumedRealVibes + refundedInPeriod still holds.

What integrators need to do

Parse chargedInPeriod in /charges and consumedVibes in /consumption/by-service and /consumption/reconstructed as a signed decimal. A negative value is the reversal of a cancelled Cowork order's seat purchase: add rows with their sign and do not drop negative ones, or the tranche's consumption for the window comes out overstated. The sign of the other export fields has not changed.

BC-0930-29: a repeated galaxy server create no longer spawns applications

Old format supported until: not provided

Before

On a Bitrix24 account where new applications land in a galaxy, a repeated or concurrent POST /v1/infra/servers with the same key could answer 201 with a different data.id and create another application.

After

While data.status for a galaxy application created with the same key is provisioning, a retry answers 201 with the same data.id and reused: true. A losing concurrent request either gets the same id or receives 409 APPLICATION_FIRST_SERVER_IN_PROGRESS. No second server or application is created. If a neighbouring request with another Idempotency-Key already started a deploy, a source supplied by the retry does not start a competing build: the response carries sourceIgnored: true but no next; poll the returned server until it leaves provisioning. If no deploy has started for the existing application, the response keeps next: "deploy", including when a retry-supplied source was ignored. A retry with the same Idempotency-Key separately remembers whether the original request accepted its source: an active original build replays as deploying: true without sourceIgnored or next, and it is not started again. After an owner/card transfer or loss of a live Galaxy host, the old id is no longer disclosed and the key remains spent. Servers created for agent or bot applications are not reused by this scenario. SERVER_CREATION_DISABLED / SERVER_CREATION_ADMINS_ONLY still forbid a new resource but do not prevent returning an existing id already owned by the caller; INFRA_NOT_PERMITTED remains an early refusal. An application that is already running, placement: "dedicated", and a Bitrix24 account whose Applications section is switched off do not prevent the next create.

What integrators need to do

When reused: true is present, continue with the returned data.id. If sourceIgnored: true is present without next, do not call deploy and do not create another server: poll GET /v1/infra/servers/{id} until it leaves provisioning. After the earlier deploy finishes, deploy the ignored source separately only if you still intend to replace that result. If the response carries next: "deploy", the existing application has no active deploy; send the code through that separate call. The previous handling without this distinction has no support window because it could start a competing build.

NEW-0930-30: Bot API warns when a registration must be replaced after a Bitrix24 account address change

Successful API responses now have an optional needsReregistration field. When the platform records a Bitrix24 account address change after this update is deployed, an empty GET /v1/bots/:botId/events response and a successful POST /v1/bots/:botId/resubscribe return the field as true for affected bots, together with an owner-aware recovery sequence. Direct deletion and re-registration are only for a standalone Bot; a bot owned by an Agent or Managed Bot must be recovered through its owner resource or support. The field is absent when events are queued. Earlier address changes are not marked automatically, so an absent field does not rule out an earlier move. The status remains HTTP 200.

BC-0930-31: Key revocation with a server outside its owner and Bitrix24 account scope

Old format supported until: not provided

Before

Revoking a key through PATCH /v1/keys/:id or POST /v1/connect/revoke could disrupt a live server owned by another user, without an owner, or owned by the same user in another Bitrix24 account.

After

These requests return 409 KEY_MANAGES_FOREIGN_SERVER before changing the key or its tokens.

What integrators should do

Set the server's owner and intended Bitrix24 account, rebind it to that owner's key in the same Bitrix24 account, then retry revocation.

NEW-0930-32: Chats: messenger v2 stickers — packs, adding, deletion and recent stickers

The chats section gained stickers on the Bitrix24 messenger v2 methods. GET /v1/chats/stickers/packs returns the user's packs page by page: the first page also carries the recent stickers, and the following pages are requested with the lastId and lastType cursor. GET /v1/chats/stickers/packs/:packId returns a pack with its stickers, PATCH on the same address renames your own pack, and DELETE deletes it. POST /v1/chats/stickers/packs/:packId/link adds another user's pack to your list, and DELETE on the same address removes it. DELETE /v1/chats/stickers/packs/:packId/stickers deletes stickers from your own pack, DELETE /v1/chats/stickers/recent clears the recent stickers list, and DELETE /v1/chats/stickers/recent/:stickerId removes one sticker from it. Built-in and user packs are numbered independently, so one number can point to two different packs, and operations on a pack require the packType parameter — vendor or custom. Deleting a pack or stickers and clearing the recent list are irreversible. The first GET /v1/chats/stickers/packs page also deletes excess recent-sticker rows and, like the other writes, answers a read-only key with 403 WRITE_BLOCKED_READONLY_KEY; cursor pages remain reads. An unknown or repeated parameter is refused with 400 INVALID_PARAMS, and the Bitrix24 refusal code arrives in error.b24Code. Creating a pack and adding stickers to it is not available through the API.

FIX-0930-33: PATCH /v1/infra/servers/{id}/access-policy spec declares accessPolicy as an enumerated string

Before

GET /v1/openapi.json described the accessPolicy field in the PATCH /v1/infra/servers/{id}/access-policy body as an object. A body built from that schema ({"accessPolicy":{}}) was rejected with 400 VALIDATION_ERROR.

After

The spec declares accessPolicy as a string from the enumeration OWNER_ONLY, NAMED_USERS, DEPARTMENT, PORTAL, AUTHENTICATED, PUBLIC — exactly what the method accepts — and documents the 400 response (VALIDATION_ERROR, BLACKHOLE_ONLY). The method's behavior is unchanged: a request with an allowed value still returns HTTP 200.

NEW-0930-34: server activity feed

GET /v1/infra/servers/{id}/activity returns a timeline of a server's failures and key events: account event delivery pauses and failures, bot delivery problems, deploy and command failures, wakes and status changes — newest first, paged with nextCursor. Every entry carries a machine-readable kind from a closed list, while code is either a value from a closed list or null: some event kinds draw no distinction of cause. An unrecognized code is reported as other. Repeats within five minutes are folded into one entry with a count. The details of a deploy or command from the feed are read with GET /v1/infra/servers/{id}/operations/{operationId} using the server owner's personal API key. The feed is being enabled gradually: until it is enabled for the server owner, both methods answer 404 SERVER_NOT_FOUND.

NEW-0930-35: Chats: personal folders — create, edit, order and contents

The chats section gained folder writes on the Bitrix24 messenger v2 methods. POST /v1/chats/folders creates a personal folder and can fill it with chats right away, GET, PATCH and DELETE /v1/chats/folders/:folderId read, edit and delete it, and PUT /v1/chats/folders/order sets the order of the folders. POST and DELETE /v1/chats/folders/:folderId/chats add and remove individual chats, and PUT /v1/chats/:dialogId/folders sets the full set of folders of one chat. GET and PUT /v1/chats/folders/:folderId/sources read and set the sources of the "All" folder: these two methods ship in the Bitrix24 im 26.1300.0 update, and a Bitrix24 account without it answers 422 METHOD_NOT_YET_AVAILABLE. Empty contents in PATCH clear the folder. The fields whose Bitrix24 default would erase data are required: folderIds of PUT /v1/chats/:dialogId/folders and sourceCodes of the sources write. A write with no effect, an unknown parameter and an invalid list element are refused with 400 INVALID_PARAMS before the Bitrix24 call. All calls except GET /v1/chats/folders/:folderId are writes: the first sources GET may persist the "All" folder composition and old pins. A read-only key gets 403 WRITE_BLOCKED_READONLY_KEY for these calls, as described on the access rights page.

NEW-0930-36: Chats: chat settings — description, color, avatar, member permissions and message auto-delete

Ten new endpoints change chat settings on the Bitrix24 messenger v2 methods. PUT /v1/chats/:dialogId/description sets the description, PUT /v1/chats/:dialogId/color sets the color to one of the seventeen palette codes, and PUT /v1/chats/:dialogId/avatar sets the avatar from a base64 image or a file on Drive. Six operations PUT /v1/chats/:dialogId/permissions/… set who posts messages, invites guests, changes permissions, changes the chat's appearance, adds members and removes them. PUT /v1/chats/:dialogId/auto-delete turns message auto-delete on with a delay of 1, 24, 168 or 720 hours, and the value 0 turns it off. A value that Bitrix24 would silently replace with its own is refused before the write with 400 INVALID_PARAMS: a color outside the palette, a permission value outside the operation's set, a string that does not read as an image. A Bitrix24 permission refusal arrives as 403 BITRIX_ACCESS_DENIED, and an avatar request body over 1 MiB as 413 PAYLOAD_TOO_LARGE. A read-only key gets 403 WRITE_BLOCKED_READONLY_KEY on all ten.

NEW-0930-40: Chats: chat links, joining by code, guest links and guest invitations

The chats section gained links and guests — 11 endpoints for links and invitations. An employee is invited with a personal chat link: POST /v1/chats/:dialogId/sharing-links/individual returns a link with a code, the code is used to join via POST /v1/chats/join-by-code, and the link is read with GET /v1/chats/sharing-links/:code, regenerated with POST /v1/chats/:dialogId/sharing-links/individual/regenerate, and revoked with DELETE /v1/chats/sharing-links/:code. People outside the Bitrix24 account are invited with a guest link or with personal invitations by email and by SMS — up to 10 per call, and the outcome of each invitation arrives in its own response entry. An unknown body field or query parameter is refused with 400 INVALID_PARAMS, and the Bitrix24 refusal code arrives in error.b24Code. Every call except reading a link by code is a write: a read-only key gets 403 WRITE_BLOCKED_READONLY_KEY for them. Vibecode does not keep the addresses and phone numbers from an invitation body in its logs.

NEW-0930-41: inventory documents and items are available through V1

/v1/catalog-documents and /v1/catalog-document-elements support reads and writes. POST /v1/catalog-documents/:id/conduct and /cancel require a write-capable key and return the refreshed status.

FIX-0930-42: outside calls to an app now count toward the key's daily allowance

Before

Calls to ANY /v1/applications/{id}/api/** went through the daily request allowance check but were never added to the key's counter: for an external API key X-RateLimit-Used always stayed 0, and X-RateLimit-Remaining stayed equal to X-RateLimit-Quota.

After

When external API metering is enabled for the Bitrix24 account, a call that the platform sent to the app and that got an answer counts toward the daily allowance of the app owner's key: either the app's own answer with any status, or the app tunnel's answer that the app is unavailable, busy or returned a response that is too large (503 APP_API_UNAVAILABLE from the tunnel, 502 APP_API_RESPONSE_TOO_LARGE). X-RateLimit-Used grows and X-RateLimit-Remaining shrinks; the counter is updated per closed hour, as for every other key. Calls above the allowance are billed at the price of a regular key request. Refusals by the platform itself never count: key and access checks, platform overload (the same 503 APP_API_UNAVAILABLE code, but without reaching the app), 429 QUOTA_EXCEEDED, 503 APP_API_TIMEOUT. Calls made before metering was enabled for the Bitrix24 account never count either: metering of an account starts when it is enabled, and if the metering settings were changed again right after that, the first minutes (less than an hour) may go uncounted, in the client's favour. Once the allowance is used up, with a paid request price on a prepaid account with no balance, the call gets 429 QUOTA_EXCEEDED, exactly like any other key request; otherwise the channel behaves as before, and the app's successful response is unchanged.

Impact on integrators

Nothing needs to change. Metering is turned on only for Bitrix24 accounts where the metering switch is enabled. The allowance and the price of a key request come from the account's plan. A 429 QUOTA_EXCEEDED refusal is possible only when the allowance is used up, the service has a non-zero price and the account is prepaid with no balance. While the price is zero, a used-up allowance shows only as X-RateLimit-Remaining equal to 0, and calls are not refused. A non-zero price is a separate decision with its own BC entry. Watch X-RateLimit-Remaining on the external API key and, on a prepaid account, keep a positive balance.

NEW-0930-43: Write catalog price types through the Vibecode API

Price types now support POST /v1/catalog-price-types, PATCH /v1/catalog-price-types/:id and DELETE /v1/catalog-price-types/:id. These routes require the catalog scope and Bitrix24 Manage price types permission. Deleting a non-base type permanently removes every product price assigned to it; the base type cannot be deleted.

NEW-0930-44: Chats: reactions, pinned messages, forwarding, in-chat search and typing

The messages section gained nine endpoints for messages and member actions. Reactions: GET /v1/chats/messages/:messageId/reactions returns the reactions to a message with the lastId cursor and a filter by code, POST /v1/chats/messages/:messageId/reactions adds your own reaction, and DELETE /v1/chats/messages/:messageId/reactions/:reaction removes it. A reaction code is written in camelCase (like, faceWithThermometer). Pinned messages: GET /v1/chats/:dialogId/pins returns a chat's pins together with the messages themselves, POST /v1/chats/messages/:messageId/pin pins a message, and DELETE /v1/chats/messages/:messageId/pin unpins it. GET /v1/chats/:dialogId/messages/search finds the messages of one chat by a substring and returns them in the shape of the v2 message history. A query shorter than three characters is rejected with 400 INVALID_PARAMS, so that search does not return the whole history instead of matches. POST /v1/chats/:dialogId/forward forwards up to 20 messages to a chat with an optional comment. The response maps the client UUID of each message to the ID of its copy and, starting with im 26.1300, names the refusals in failureMap. POST /v1/chats/:dialogId/typing shows the chat members that the user is typing, recording a voice message or sending a file. The reactions list, the pins list and search may make the user a chat member when the chat allows auto-join, so they count as writes: a read-only key gets 403 WRITE_BLOCKED_READONLY_KEY for them, as described on the access rights page.

NEW-0930-45: Chats: anchors, channel comments, message blocks and the number of pinned messages

The chats section gained ten operations around a message on the Bitrix24 messenger v2 methods. Anchors — the marks of unread mentions and reactions — are removed in a whole chat with POST /v1/chats/:dialogId/anchors/read or on selected messages with POST /v1/chats/anchors/read. Channel comments: GET /v1/chats/messages/comments returns a summary of comment threads per post, POST /v1/chats/:dialogId/comments/read-all marks all channel comments as read, and POST and DELETE /v1/chats/messages/:messageId/comments/subscription turn notifications about new comments on a post on and off. Blocks of a constructor message are added, replaced and deleted with POST /v1/chats/messages/:messageId/blocks, PATCH and DELETE /v1/chats/messages/:messageId/blocks/:blockId. The number of pinned messages comes from GET /v1/chats/:dialogId/pins/count. Invalid input is refused with 400 INVALID_PARAMS before any call to Bitrix24, and the Bitrix24 refusal code arrives in error.b24Code. Removing anchors is a write although the Bitrix24 method is called read, and counting pinned messages may make the user a member of a chat that allows auto-join, so a read-only key gets 403 WRITE_BLOCKED_READONLY_KEY for them, as described on the access rights page. The comment summary stays a read.

FIX-0930-46: restore the existing event polling response

GET /v1/chats/events again returns HTTP 200 with an empty feed and the previous offset when Bitrix24 omits the result. The response and Bitrix24 account call follow main before stage 2; the new 502 refusal for this case is removed.

FIX-0930-47: restore the task feed fallback

GET /v1/tasks/{taskId}/chat/messages again treats a machine code containing METHOD_NOT_FOUND as an unavailable v2 surface and falls back to the legacy method. The existing cache and read contract are retained; READONLY still uses the legacy path.