# API changes: September 30, 2026 [← Changelog](/docs/changelog) · [September 2026](/docs/changelog/2026-09) ### NEW-0930-1: Chats: messenger settings and v2 service methods The chats section gained [messenger settings](/docs/chats/settings) and [service methods](/docs/chats/service) on the Bitrix24 messenger v2 methods. [GET /v1/chats/settings](/docs/chats/settings/general) reads the user's general settings, `PATCH` on the same address changes one setting, and [PUT /v1/chats/settings/status](/docs/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](/docs/chats/service/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](/docs/chats/service/flow-form) the flow form data of a collab. [POST /v1/chats/:dialogId/bot-context](/docs/chats/service/bot-context) hands a context to the chat's bots, and [POST /v1/chats/:dialogId/zoom](/docs/chats/service/zoom) creates a Zoom meeting and posts the invitation to the chat. [GET /v1/chats/state](/docs/chats/service/state) returns the update state and counters, [GET /v1/chats/tariff-restrictions](/docs/chats/service/tariff-restrictions) the plan restrictions, [GET /v1/chats/promotions](/docs/chats/service/promotions) the active promo hints, and [GET /v1/chats/users/:userId/department](/docs/chats/service/department) the user's department. [POST /v1/chats/desktop/logout](/docs/chats/service/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](/docs/chats/management/unread) set and clear the "unread" mark on the chat's row in the recent dialog list, and [POST /v1/chats/messages/:messageId/mark](/docs/chats/messages/mark) marks the message the chat opens at next time — "read later"; the same `DELETE` clears it. [GET /v1/chats/:dialogId/users/mentionable](/docs/chats/members/mentionable) returns the chat members who can be mentioned with `@`, and [GET /v1/chats/:dialogId/users/membership](/docs/chats/members/membership) checks which of the given users are chat members. [GET /v1/chats/folders](/docs/chats/discovery/folders) returns the user's chat folders — the messenger's system sections and personal folders, and [GET /v1/chats/folders/:folderId/recent](/docs/chats/discovery/folder-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](/docs/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](/docs/chats/files/upload) 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](/docs/chats/files/save) copies chat files to the user's Drive, [POST /v1/chats/files/:fileId/transcribe](/docs/chats/files/transcribe) starts the transcription of an audio or video file. The [CoPilot](/docs/chats/copilot) section opens the CoPilot draft chat ([POST /v1/chats/copilot/draft](/docs/chats/copilot/draft)), switches the assistant's model and role ([PUT /v1/chats/:dialogId/copilot/engine](/docs/chats/copilot/engine), [PUT /v1/chats/:dialogId/copilot/role](/docs/chats/copilot/role)), asks it to regenerate an answer ([POST /v1/chats/messages/:messageId/regenerate](/docs/chats/copilot/regenerate)) and rates the answer ([POST /v1/chats/messages/:messageId/vote](/docs/chats/copilot/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](/docs/chats/files/file-get) 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](/docs/chats/files/upload) 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](/docs/chats/files/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](/docs/chats/members/managers-add) assigns managers, [PUT /v1/chats/:dialogId/managers](/docs/chats/members/managers-set) replaces their whole list, and [DELETE /v1/chats/:dialogId/managers](/docs/chats/members/managers-remove) removes the role. [GET /v1/chats/:dialogId/member-entities](/docs/chats/members/member-entities) returns the chat members as "type — ID" pairs together with linked departments, [GET /v1/chats/:dialogId/users/active](/docs/chats/members/active) returns members in the chosen sort order, for example the most active ones, and [GET /v1/chats/:dialogId/users/relations](/docs/chats/members/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](/docs/chats/members/list) returns members with their roles in pages by a cursor, [POST /v1/chats/:chatId/users](/docs/chats/members/add) and [DELETE /v1/chats/:chatId/users](/docs/chats/members/remove) add and remove members, and [POST /v1/chats/:chatId/owner](/docs/chats/management/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](/docs/access-rights) page. ### FIX-0930-6: restore legacy member-list parameters for ordinary keys [GET /v1/chats/{dialogId}/users](/docs/chats/members/list) 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](/docs/chats/management/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](/docs/chats/management/delete) 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](/docs/chats/management/join) joins an open chat, [PUT and DELETE /v1/chats/:dialogId/parent](/docs/chats/management/parent) attach a chat to a parent chat and detach it, [GET /v1/chats/access](/docs/chats/discovery/access) checks access to a chat or a message, [POST /v1/chats/dialog-id](/docs/chats/discovery/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](/docs/chats/messages/load-in-context) opens a chat around the given message. Four existing endpoints gained modes: `format=v2` on the [dialog card](/docs/chats/discovery/get), on chat [creation](/docs/chats/management/create) and on chat [renaming](/docs/chats/management/rename) — 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](/docs/chats/messages/load) — 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](/docs/access-rights). ### FIX-0930-9: legacy chat creation for an ordinary key [POST /v1/chats](/docs/chats/management/create) 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](/docs/chats/management/rename) 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](/docs/chats/discovery/get) again forwards raw query parameters for an ordinary key, as in `main bd93898fc422`; READONLY retains the path dialog binding. [POST /v1/chats/:chatId/leave](/docs/chats/management/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](/docs/infra/app-runtime) 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](/docs/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](/docs/notifications/read-all) marks every notification as read except those listed in `excludeIds`. [DELETE /v1/notifications](/docs/notifications/delete-all) 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](/docs/notifications/groups), group conditions through [/v1/notifications/groups/:groupId/conditions](/docs/notifications/group-conditions); removing the last condition deletes the group too. [GET /v1/notifications/settings](/docs/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](/docs/search/run) 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](/docs/search/run) and [POST /v1/research](/docs/search/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](/docs/bots/events/polling) 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//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}](/docs/feed/posts/update), [DELETE /v1/posts/{id}](/docs/feed/posts/delete) and [POST /v1/posts/{id}/share](/docs/feed/posts/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](/docs/feed/comments/add) and [DELETE /v1/posts/{id}/comments/{commentId}](/docs/feed/comments/delete) 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 not found or not accessible with this key.`, and for [DELETE /v1/posts/{id}/comments/{commentId}](/docs/feed/comments/delete) 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](/docs/chats/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](/docs/chats/messages/viewers) returns who viewed a message and when, in pages by the `lastId` cursor. [POST /v1/chats/messages/:messageId/disappear](/docs/chats/messages/disappear) sets a deletion timer on a message, [POST /v1/chats/messages/:messageId/inform](/docs/chats/messages/inform) delivers it to a recipient in Do Not Disturb as an important notification, [DELETE /v1/chats/messages/:messageId/url-preview](/docs/chats/messages/url-preview) removes a link preview, and [POST /v1/chats/messages/read](/docs/chats/messages/read) marks the selected messages as read — from 1 to 100 per request. Sending, [editing](/docs/chats/messages/update), [deleting](/docs/chats/messages/delete) 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](/docs/access-rights) page. ### FIX-0930-21: restore partial legacy message batch results [POST /v1/chats/messages/bulk](/docs/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](/docs/chats/messages/update) and [DELETE](/docs/chats/messages/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](/docs/chats/messages/list) 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](/docs/chats/messages/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](/docs/chats/messages/send) 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](/docs/chats/messages/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](/docs/infra/servers/create) 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](/docs/bots/events/polling) response and a successful [POST /v1/bots/:botId/resubscribe](/docs/bots/management/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](/docs/management-keys) or [POST /v1/connect/revoke](/docs/partner-connect) 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](/docs/chats/stickers) on the Bitrix24 messenger v2 methods. [GET /v1/chats/stickers/packs](/docs/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](/docs/chats/stickers/pack) 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](/docs/chats/stickers/link) adds another user's pack to your list, and `DELETE` on the same address removes it. [DELETE /v1/chats/stickers/packs/:packId/stickers](/docs/chats/stickers/pack-stickers) deletes stickers from your own pack, [DELETE /v1/chats/stickers/recent](/docs/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](/docs/chats/management/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](/docs/chats/management/folder-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](/docs/chats/management/folder-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](/docs/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](/docs/chats/management/description) sets the description, [PUT /v1/chats/:dialogId/color](/docs/chats/management/color) sets the color to one of the seventeen palette codes, and [PUT /v1/chats/:dialogId/avatar](/docs/chats/management/avatar) sets the avatar from a base64 image or a file on Drive. Six operations [PUT /v1/chats/:dialogId/permissions/…](/docs/chats/management/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](/docs/chats/management/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](/docs/chats/sharing) — 11 endpoints for links and invitations. An employee is invited with a personal chat link: [POST /v1/chats/:dialogId/sharing-links/individual](/docs/chats/sharing/individual-link) returns a link with a code, the code is used to join via [POST /v1/chats/join-by-code](/docs/chats/sharing/join), and the link is read with [GET /v1/chats/sharing-links/:code](/docs/chats/sharing/link-get), regenerated with [POST /v1/chats/:dialogId/sharing-links/individual/regenerate](/docs/chats/sharing/individual-link-regenerate), and revoked with [DELETE /v1/chats/sharing-links/:code](/docs/chats/sharing/link-revoke). People outside the Bitrix24 account are invited with a [guest link](/docs/chats/sharing/guest-link) or with personal invitations [by email](/docs/chats/sharing/invite-email) and [by SMS](/docs/chats/sharing/invite-phone) — 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](/docs/chats/messages/reactions) returns the reactions to a message with the `lastId` cursor and a filter by code, [POST /v1/chats/messages/:messageId/reactions](/docs/chats/messages/reactions) adds your own reaction, and [DELETE /v1/chats/messages/:messageId/reactions/:reaction](/docs/chats/messages/reactions) removes it. A reaction code is written in camelCase (`like`, `faceWithThermometer`). Pinned messages: [GET /v1/chats/:dialogId/pins](/docs/chats/messages/pins) returns a chat's pins together with the messages themselves, [POST /v1/chats/messages/:messageId/pin](/docs/chats/messages/pins) pins a message, and [DELETE /v1/chats/messages/:messageId/pin](/docs/chats/messages/pins) unpins it. [GET /v1/chats/:dialogId/messages/search](/docs/chats/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](/docs/chats/messages/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](/docs/chats/messages/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](/docs/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](/docs/chats/messages/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](/docs/chats/messages/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](/docs/chats/messages/blocks) 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](/docs/chats/messages/pins) 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](/docs/access-rights) page. The comment summary stays a read. ### FIX-0930-46: restore the existing event polling response [GET /v1/chats/events](/docs/chats/events/poll) 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.