# Изменения API: 30 сентября 2026

[← Журнал изменений](/docs/changelog) · [Сентябрь 2026](/docs/changelog/2026-09)

### NEW-0930-1: Чаты: настройки мессенджера и служебные методы v2

В разделе чатов появились [настройки мессенджера](/docs/chats/settings) и [служебные методы](/docs/chats/service) на методах мессенджера v2 Битрикс24. [GET /v1/chats/settings](/docs/chats/settings/list) читает общие настройки пользователя, `PATCH` того же адреса меняет одну настройку, а [PUT /v1/chats/settings/status](/docs/chats/settings/status) устанавливает статус — `online`, `dnd` или `away`. Без `userId` операции работают с настройками владельца ключа, чужие настройки доступны только администратору Битрикс24. [GET /v1/chats/:dialogId/task-form](/docs/chats/service/task-form) и `POST /v1/chats/messages/:messageId/task-form` отдают данные формы создания задачи из чата и из сообщения, а [GET /v1/chats/:dialogId/flow-form](/docs/chats/service/flow-form) — формы потока коллаба. [POST /v1/chats/:dialogId/bot-context](/docs/chats/service/bot-context) передаёт контекст ботам чата, а [POST /v1/chats/:dialogId/zoom](/docs/chats/service/zoom) создаёт конференцию Zoom с приглашением в чат. [GET /v1/chats/state](/docs/chats/service/state) отдаёт состояние обновлений и счётчики, [GET /v1/chats/tariff-restrictions](/docs/chats/service/tariff-restrictions) — ограничения тарифа, [GET /v1/chats/promotions](/docs/chats/service/promotions) — активные промо-подсказки, [GET /v1/chats/users/:userId/department](/docs/chats/service/department) — отдел пользователя. [POST /v1/chats/desktop/logout](/docs/chats/service/desktop-logout) отмечает десктоп-приложение «не в сети». Формы задачи и потока могут сделать вызывающего участником чата, как открытие чата. Чтение состояния обновлений отмечает пользователя «в сети», а чтение общих настроек может создать привязку к их набору. Поэтому ключ только для чтения получает на этих `GET`-маршрутах и на остальных изменяющих операциях `403 WRITE_BLOCKED_READONLY_KEY`. Неизвестный или повторный параметр отклоняется с `400 INVALID_PARAMS`, код отказа Битрикс24 приходит в `error.b24Code`.

### NEW-0930-2: Чаты: метка «непрочитано», «прочитать позже», упоминания, проверка участия и папки чатов

Раздел чатов получил семь эндпоинтов на методах мессенджера v2 Битрикс24. [POST и DELETE /v1/chats/:dialogId/unread](/docs/chats/management) ставят и снимают метку «непрочитано» на строке чата в списке последних диалогов, а [POST /v1/chats/messages/:messageId/mark](/docs/chats/messages/mark) отмечает сообщение, с которого чат откроется в следующий раз, — «прочитать позже»; снимается он тем же `DELETE`. [GET /v1/chats/:dialogId/users/mentionable](/docs/chats/members/mentionable) отдаёт участников чата, которых можно упомянуть через `@`, а [GET /v1/chats/:dialogId/users/membership](/docs/chats/members/membership) проверяет, кто из переданных пользователей состоит в чате. [GET /v1/chats/folders](/docs/chats/discovery/folders) возвращает папки чатов пользователя — системные разделы мессенджера и личные папки, а [GET /v1/chats/folders/:folderId/recent](/docs/chats/discovery/folder-recent) — список чатов одной папки страницами по курсору `lastMessageDate`. Неизвестный или повторный параметр отклоняется с `400 INVALID_PARAMS`, код отказа Битрикс24 приходит в `error.b24Code`. Метка и «прочитать позже» остаются изменяющими вызовами и получают `403 WRITE_BLOCKED_READONLY_KEY` с ключом только для чтения. Упоминания и проверка участия доступны обычному личному ключу сотрудника только для существующего чата по контракту [прав доступа](/docs/access-rights); в чате, допускающем автовступление, они могут сделать пользователя участником; `GET /v1/chats/folders` также блокируется: портал может создать папки и перенести закрепления; список чатов уже известной папки остаётся чтением.

### NEW-0930-3: Чаты: файлы и CoPilot на методах мессенджера v2

[POST /v1/chats/:chatId/files](/docs/chats/files/upload) с параметром `format=v2` загружает файл и публикует сообщение одним вызовом мессенджера v2 и отвечает `200` с сущностью файла, `messageId`, `chatId` и `dialogId`. Без `format=v2` загрузка отвечает как раньше. Новые эндпоинты: [POST /v1/chats/files/save](/docs/chats/files/save) копирует файлы чата на Диск пользователя, [POST /v1/chats/files/:fileId/transcribe](/docs/chats/files/transcribe) запускает расшифровку аудио- или видеофайла. Раздел [CoPilot](/docs/chats/copilot) открывает черновой чат CoPilot ([POST /v1/chats/copilot/draft](/docs/chats/copilot/draft)), меняет модель и роль ассистента ([PUT /v1/chats/:dialogId/copilot/engine](/docs/chats/copilot/engine), [PUT /v1/chats/:dialogId/copilot/role](/docs/chats/copilot/role)), просит переписать ответ ([POST /v1/chats/messages/:messageId/regenerate](/docs/chats/copilot/regenerate)) и оценивает его ([POST /v1/chats/messages/:messageId/vote](/docs/chats/copilot/vote)). Все новые операции изменяющие: ключ только для чтения получает `403 WRITE_BLOCKED_READONLY_KEY`. Неизвестное, отсутствующее или некорректное поле тела отклоняется с `400 INVALID_PARAMS` до обращения к Битрикс24, код отказа портала приходит в `error.b24Code`. Ссылки на файл в ответах этих операций открываются только в сессии пользователя в Битрикс24 и учётных данных портала не несут.

### FIX-0930-4: прежние метаданные файла для обычного ключа

[GET /v1/chats/files/:fileId](/docs/chats/files/file-get) снова требует только `im` и возвращает `downloadUrl` обычному ключу, как раньше. READONLY сохраняет дополнительный `disk` и не получает ссылку.

[POST /v1/chats/:chatId/files](/docs/chats/files/upload) без `format=v2` снова выполняет прежние три шага с повторами, как раньше, возвращает `downloadUrl`, не добавляет `502` на `commit=false` и не вызывает `disk.file.delete`. Связанные запреты повтора в очереди и восстановлении скоупов сняты; READONLY отказ записи сохранён.

[GET /v1/chats/:chatId/folder](/docs/chats/files/folder) для обычного ключа снова передаёт сырые query-параметры, как раньше. READONLY отказ возможной инициализации папки сохранён.

### NEW-0930-5: Чаты: участники на мессенджере v2 — менеджеры, состав по сущностям, активные участники и записи участия

Раздел участников чата получил операции на методах мессенджера v2 Битрикс24. Менеджерами чата управляют три новых эндпоинта: [POST /v1/chats/:dialogId/managers](/docs/chats/members/managers-add) назначает менеджеров, [PUT /v1/chats/:dialogId/managers](/docs/chats/members/managers-set) заменяет их список целиком, а [DELETE /v1/chats/:dialogId/managers](/docs/chats/members/managers-remove) снимает роль. [GET /v1/chats/:dialogId/member-entities](/docs/chats/members/member-entities) отдаёт состав чата парами «тип — ID» вместе с подключёнными подразделениями, [GET /v1/chats/:dialogId/users/active](/docs/chats/members/active) — участников с выбранной сортировкой, например самых активных, а [GET /v1/chats/:dialogId/users/relations](/docs/chats/members/relations) — роли названных пользователей в чате. Параметр `format=v2` появился у четырёх прежних эндпоинтов: [GET /v1/chats/:dialogId/users](/docs/chats/members/list) отдаёт участников с ролями страницами по курсору, [POST /v1/chats/:chatId/users](/docs/chats/members/add) и [DELETE /v1/chats/:chatId/users](/docs/chats/members/remove) добавляют и удаляют участников, а [POST /v1/chats/:chatId/owner](/docs/chats/management/owner) передаёт владение — и только участнику чата. Без `format=v2` все четыре отвечают как раньше. В новых эндпоинтах и в режиме v2 неизвестный или повторный параметр отклоняется с `400 INVALID_PARAMS`, а код отказа портала приходит в `error.b24Code` у ответов `422` и `404`. Чтения новых эндпоинтов и список участников в режиме v2 могут сделать пользователя участником чата, если чат разрешает автовступление. Ключу только для чтения они доступны, если это личный ключ сотрудника и чат уже существует. Остальные ключи только для чтения получают на них `403 WRITE_BLOCKED_READONLY_KEY` — см. [права доступа](/docs/access-rights).

### FIX-0930-6: прежние параметры легаси-списка участников для обычного ключа

[GET /v1/chats/{dialogId}/users](/docs/chats/members/list) снова передаёт дополнительные сырые query-параметры обычного ключа, как раньше. Фильтрация параметров сохраняется только для ключа READONLY; режим `format=v2` не меняется.

### FIX-0930-7: прежняя передача полей при смене владельца чата

[POST /v1/chats/{chatId}/owner](/docs/chats/management/owner) снова передаёт остальные поля тела обычного ключа в Битрикс24, как раньше. Подтверждённый `CHAT_ID` и `USER_ID` по-прежнему ставятся последними. READONLY-ключу запись отклоняется до обращения к Битрикс24; режим `format=v2` не меняется.

### NEW-0930-8: Чаты: мессенджер v2 — удаление, вступление, родительский чат, проверка доступа и режимы v2 карточки, создания и изменения чата

Раздел чатов получил семь эндпоинтов на методах мессенджера v2 Битрикс24. [DELETE /v1/chats/:dialogId](/docs/chats/management/delete) удаляет групповой чат для всех участников вместе с сообщениями и файлами — **необратимо**; ответ приходит раньше фактического удаления. [POST /v1/chats/:dialogId/join](/docs/chats/management/join) вступает в открытый чат, [PUT и DELETE /v1/chats/:dialogId/parent](/docs/chats/management/parent) привязывают чат к родительскому и отвязывают от него, [GET /v1/chats/access](/docs/chats/discovery/access) проверяет доступ к чату или сообщению, [POST /v1/chats/dialog-id](/docs/chats/discovery/dialog-id) возвращает ID диалога по ID пользователя, CRM-сущности или рабочей группы и создаёт чат, если его ещё нет, а [GET /v1/chats/messages/:messageId/load](/docs/chats/messages/load-in-context) открывает чат вокруг указанного сообщения. Четыре существующих эндпоинта получили режимы: `format=v2` у [карточки диалога](/docs/chats/discovery/get), [создания](/docs/chats/management/create) и [переименования](/docs/chats/management/rename) чата — последний в этом режиме меняет чат целиком: описание, аватар, владельца, права, участников и менеджеров, — и `shallow=true` у [загрузки чата](/docs/chats/messages/load) — карточка, участники и контекст без страницы сообщений. Без параметра эти эндпоинты отвечают как раньше. Поля тела проверяются до обращения к Битрикс24: неизвестное поле или значение вне списка отклоняется с `400 INVALID_PARAMS`. Карточка в режиме v2, облегчённая загрузка, проверка доступа и загрузка вокруг сообщения могут сделать пользователя участником чата, если чат разрешает автовступление. Ключу только для чтения они доступны, если это личный ключ сотрудника и чат уже существует. Остальные ключи только для чтения получают на них `403 WRITE_BLOCKED_READONLY_KEY`. На новых изменяющих эндпоинтах этот отказ получает любой ключ только для чтения — см. [права доступа](/docs/access-rights).

### FIX-0930-9: прежнее создание чата для обычного ключа

[POST /v1/chats](/docs/chats/management/create) без `format=v2` снова передаёт список `users` и сырые легаси-параметры в Битрикс24 без нового `400 INVALID_PARAMS`, как раньше. Отказ READONLY на запись и заготовка режима v2 сохранены.

[PATCH /v1/chats/:chatId](/docs/chats/management/rename) снова продолжает переименование при временном отказе проверки членства, как раньше: без нового `503` и лимита проверок. Проверка с подтверждённым отказом доступа по-прежнему возвращает `404`.

[GET /v1/chats/:dialogId](/docs/chats/discovery/get) для обычного ключа снова передаёт сырые query-параметры, как раньше; READONLY сохраняет привязку к диалогу из пути.

[POST /v1/chats/:chatId/leave](/docs/chats/management/leave) для обычного ключа снова передаёт сырые поля тела в Битрикс24, как раньше. Отказ READONLY на запись сохранён.

### NEW-0930-10: Загрузка и удаление изображений товара

`POST /v1/catalog-products/:productId/images` загружает картинку. `DELETE /v1/catalog-products/:productId/images/:imageId` удаляет её. Ответ загрузки содержит безопасные метаданные без URL с секретом вебхука.

### BC-0930-11: Приложение возвращает клиенту исходный редирект

> Поддержка старого формата до: не предусмотрена

**Было**

При ответе приложения с редиректом платформа сама переходила по `Location`. Клиент получал последний ответ вместо исходного `3xx`, а cookie первого ответа терялись.

**Стало**

[Приложения на Black Hole](/docs/infra/app-runtime) возвращают исходный `301`, `302`, `303`, `307` или `308`, `Location` и обычные cookie по существующим правилам. При открытии публичного адреса приложения абсолютный `Location` на его точный внутренний адрес заменяется публичным адресом. Внешние и относительные адреса не меняются. Политика cookie платформы и специальные ответы `/robots.txt` сохраняются.

**Что делать интеграторам**

Если HTTP-клиент рассчитывал на переход со стороны платформы, обрабатывайте `3xx` и переходите по `Location` на стороне клиента с подходящей вам политикой безопасности. Для собственного OAuth явно настройте публичный callback URL: вложенный `redirect_uri` не переписывается. Сервисные вызовы внешнего API приложения не получают перепись абсолютного адреса или cookie ответа.

### NEW-0930-12: Уведомления: мессенджер v2 — отметка по списку, отметка всех, удаление всех, группы и настройки доставки

Раздел уведомлений получил операции на методах мессенджера v2 Битрикс24. [POST /v1/notifications/read](/docs/notifications/read) с параметром `format=v2` отмечает прочитанными ровно названные уведомления — тело `{ "ids": [...] }`, до 100 идентификаторов, ответ `{ counter, viewedMessages }`; без `format=v2` эндпоинт отвечает как раньше. [POST /v1/notifications/read-all](/docs/notifications/read-all) отмечает прочитанными все уведомления, кроме перечисленных в `excludeIds`. [DELETE /v1/notifications](/docs/notifications/delete-all) необратимо удаляет все уведомления владельца ключа и принимает только голый адрес: любой параметр запроса или поле тела отклоняется с `400 INVALID_PARAMS`. Группы уведомлений читаются, создаются, переименовываются и удаляются через [/v1/notifications/groups](/docs/notifications/groups), условия группы — через [/v1/notifications/groups/:groupId/conditions](/docs/notifications/groups); удаление последнего условия удаляет и группу. [GET /v1/notifications/settings](/docs/notifications/settings) отдаёт настройки доставки по каналам, `PATCH` включает или выключает один канал события, а `PUT /v1/notifications/settings/scheme` переключает режим настроек; переход в простой режим переписывает настройки отдельных событий, и возврат в расширенный их не восстанавливает. Неизвестный, повторный или некорректный параметр отклоняется с `400 INVALID_PARAMS` до обращения в Битрикс24, код отказа портала приходит в `error.b24Code` у ответов `422` и `404`. Чтение групп и настроек доступно ключу только для чтения, остальные операции отвечают ему `403 WRITE_BLOCKED_READONLY_KEY`.

### NEW-0930-13: настройки веб-поиска портала — режим advanced и суточный потолок расхода

Администратор портала может выключить режим `advanced` и задать суточный потолок расхода на платный поиск. Настройки действуют на поиск через движок платформы. Поиск на собственном ключе провайдера они не затрагивают.

Если режим `advanced` выключен, [POST /v1/search](/docs/search/run) с `search_depth: "advanced"` выполняется в режиме `basic`, и запрос не отклоняется. В ответе и в событиях SSE `start` и `done` приходит `search_depth: "basic"`, списание идёт по цене `basic`, а в заголовках ответа появляется `X-Search-Depth-Downgraded: advanced`.

Перед платным запросом уже учтённый расход портала за сутки по московскому времени складывается со стоимостью этого запроса. Если сумма превысит потолок, [POST /v1/search](/docs/search/run) и [POST /v1/research](/docs/search/research) отвечают `429 SEARCH_DAILY_CAP_REACHED` с заголовком `Retry-After` и полем `resetAt` до начала следующих суток. Параллельные запросы могут пройти проверку по одному остатку, поэтому итоговый расход может превысить потолок. Для порталов без настроек поведение не меняется.

### FIX-0930-14: `/v1/oauth/authorize` отвергает `state` с префиксом `open-app:`

**Было**

Любое значение `state` сохранялось как есть.

**Стало**

`state`, начинающийся с `open-app:`, отвечает 400 `INVALID_REQUEST`: префикс зарезервирован за внутренним потоком открытия приложения из каталога.

### FIX-0930-15: повтор опроса событий бота сразу после ошибки больше не получает 409

**Было**

[GET /v1/bots/:botId/events](/docs/bots/events/polling) отдавал ошибку Битрикс24 (например, `403 BITRIX_ACCESS_DENIED`) раньше, чем опрос этого бота считался завершённым. Немедленный повторный опрос мог получить `409 BOT_EVENTS_BUSY`, хотя первый уже ответил.

**Стало**

Ошибка отдаётся только после завершения опроса, поэтому следующий опрос сразу получает свой собственный ответ. Коды и статусы ошибок не изменились, успешный ответ HTTP 200 тоже прежний.

### BC-0930-16: POST aggregate отклоняет поля устаревшего формата вне массива

> Поддержка старого формата до: не предусмотрена

**Было**

`POST /v1/<entity>/aggregate` принимал тело вида `{ "op": "sum", "field": "amount" }`, игнорировал запрошенную операцию и возвращал HTTP 200 с количеством записей.

**Стало**

Такой запрос возвращает HTTP 400 `INVALID_PARAMS` с примером корректного массива `aggregate`. На маршрутах, где пустое тело или переданный `filter` уже удовлетворяли обязательным для сущности условиям, они по-прежнему запрашивают количество записей.

**Что делать интеграторам**

Передавать выражения в массиве: `{ "aggregate": [{ "field": "amount", "function": "sum" }] }`.

### FIX-0930-17: кнопка ключа в пустом слоте списка приложений

**Было**

В `GET /v1/applications` у карточки с пустым личным слотом поле `key.rotatable` оставалось `false`, а `key.rotateBlockedReason` — `ISSUANCE_BLOCKED`, если у портала не было коммерческого тарифа. Держатель платного места Коворка видел то же, что и портал без права на ключ.

**Стало**

Для этого держателя `key.rotatable` становится `true`, а `key.rotateBlockedReason` — `null`. Ответ списка остаётся HTTP 200. Квота, выключенная инфраструктура и политика только чтения по-прежнему гасят кнопку.

### FIX-0930-18: у занятого сервера машинное поле больше не зовёт ручку, которая ответит отказом

**Было**

У отказа `409 EXEC_BUSY` на сервере `kind: STANDALONE` поле `error.hint.recoveryAction` всегда содержало `POST /v1/infra/servers/:id/unstick`. В том числе когда тот же ответ уже называет живого держателя в `error.hint.holder` или показывает, что замок ещё не истёк (`error.hint.autoExpiresInSeconds` больше нуля). Вызов этой ручки без `force` в таком состоянии отвечает `409 OPERATION_IN_PROGRESS`.

**Стало**

Если в ответе есть `error.hint.holder` или `error.hint.autoExpiresInSeconds` больше нуля, `error.hint.recoveryAction` — директива ожидания: дождаться окончания названной операции и повторить тот же вызов. Эндпоинта в поле нет. `POST /v1/infra/servers/:id/unstick` остаётся в поле только когда держателя нет и `autoExpiresInSeconds` равен нулю. Сам отказ не меняется: это по-прежнему `409 EXEC_BUSY` с `retryable: true` и заголовком `Retry-After`. Текст `error.hint.recovery` прежний.

### FIX-0930-19: ответы о ненайденном посте и отказы по id поста и получателям отдают сообщение на английском

**Было**

[PATCH /v1/posts/{id}](/docs/feed/posts/update), [DELETE /v1/posts/{id}](/docs/feed/posts/delete) и [POST /v1/posts/{id}/share](/docs/feed/posts/share) при отказе Битрикс24 с кодами `404 POST_NOT_FOUND`, `400 INVALID_POST_ID` и `400 INVALID_RECIPIENTS` отдавали в `error.message` текст портала как есть. Так же отвечали [POST /v1/posts/{id}/comments](/docs/feed/comments/add) и [DELETE /v1/posts/{id}/comments/{commentId}](/docs/feed/comments/delete) на отказ с кодом `404 POST_NOT_FOUND`. На портале с русским языком это был русский текст.

**Стало**

`error.message` таких ответов — фиксированный английский текст. Для `404 POST_NOT_FOUND` это `Post <id> not found or not accessible with this key.`, а у [DELETE /v1/posts/{id}/comments/{commentId}](/docs/feed/comments/delete) — `Post or comment not found or not accessible with this key.`, потому что этот ответ не уточняет, что именно не найдено, пост или комментарий. Для `400 INVALID_POST_ID` — `Bitrix24 rejected the post id.`, для `400 INVALID_RECIPIENTS` — `Bitrix24 rejected one or more recipients.` Коды и статусы прежние.

**Влияние на интеграторов**

Код клиента, который ветвится по `error.code`, менять не нужно. Разбор текста `error.message` этих ответов больше не требуется.

### NEW-0930-20: Чаты: сообщения на методах мессенджера v2 — первая страница, просмотры, исчезающие сообщения и отметка прочитанного

Раздел чатов получил шесть новых эндпоинтов на методах мессенджера v2 Битрикс24. [GET /v1/chats/:dialogId/messages/initial](/docs/chats/messages/initial) отдаёт первую страницу чата — вокруг отметки непрочитанного или последнего прочитанного сообщения, [GET /v1/chats/messages/:messageId/viewers](/docs/chats/messages/viewers) — кто и когда просмотрел сообщение, страницами по курсору `lastId`. [POST /v1/chats/messages/:messageId/disappear](/docs/chats/messages/disappear) ставит сообщению таймер удаления, [POST /v1/chats/messages/:messageId/inform](/docs/chats/messages/inform) доставляет его собеседнику в режиме «Не беспокоить» как важное уведомление, [DELETE /v1/chats/messages/:messageId/url-preview](/docs/chats/messages/url-preview) убирает превью ссылки, а [POST /v1/chats/messages/read](/docs/chats/messages/read) отмечает прочитанными выбранные сообщения — от 1 до 100 за запрос. Отправка, [редактирование](/docs/chats/messages/update), [удаление](/docs/chats/messages/delete) и отметка чата прочитанным получили режим `format=v2`: правка меняет не только текст, но и вложения, клавиатуру, меню и блоки, а правка и удаление проверяют, что сообщение лежит в диалоге из пути, и иначе отвечают `404 ENTITY_NOT_FOUND`, ничего не меняя. Без `format=v2` эти эндпоинты отвечают как раньше. Неверный вход отклоняется с `400 INVALID_PARAMS` до обращения к Битрикс24, код отказа портала приходит в `error.b24Code`. Первая страница и просмотры могут сделать пользователя участником чата с автовступлением, поэтому ключ только для чтения получает на них `403 WRITE_BLOCKED_READONLY_KEY`, как описано на странице [прав доступа](/docs/access-rights).

### FIX-0930-21: прежние частичные результаты пакета сообщений

[POST /v1/chats/messages/bulk](/docs/chats/messages/bulk) снова сохраняет легаси-обработку повторов, типов и частичного HTTP 200 результата, как раньше. Новые местные отказы 400 и требование полного соответствия результатов со статусом 502 сняты. Центральная защита READONLY остаётся условной по ключу.

### FIX-0930-22: прежнее изменение сообщений в обычном режиме

Легаси [PATCH](/docs/chats/messages/update) и [DELETE](/docs/chats/messages/delete) снова передают команду Битрикс24 без дополнительного чтения принадлежности диалогу и новых отказов 404/503. Проверка READONLY предшествует записи. Режим `format=v2` сохраняет свой отдельный контракт.

### FIX-0930-23: прежние параметры легаси-ленты для обычного ключа

[GET /v1/chats/{dialogId}/messages](/docs/chats/messages/list) снова передаёт дополнительные сырые параметры обычного ключа, как раньше. Фильтрация селекторов и пагинации сохраняется только для ключа READONLY; режим `format=v2` не меняется.

### FIX-0930-24: прежняя обработка отметки прочтения

Легаси [POST /v1/chats/{dialogId}/read](/docs/chats/messages/read) снова пропускает непригодный `messageId` вместо нового отказа 400 и сохраняет прежнюю передачу ID диалога. Ключ READONLY по-прежнему получает отказ до записи. Режим `format=v2` не меняется.

### FIX-0930-25: прежняя передача полей при отправке сообщения

Легаси [POST /v1/chats/{dialogId}/messages](/docs/chats/messages/send) для обычного ключа снова передаёт дополнительные поля тела в Битрикс24 вместе с каноническими `DIALOG_ID` и `MESSAGE`, как раньше. Проверки READONLY сохраняются.

### FIX-0930-26: запрет просмотра сообщения для ключа только для чтения

[GET /v1/chats/messages/{messageId}/viewers](/docs/chats/messages/viewers) может добавить пользователя в чат. Ключи `READONLY` теперь получают `403 WRITE_BLOCKED_READONLY_KEY` до обращения к Битрикс24.

### FIX-0930-27: распознавание речи на отключённую модель отвечает 404 до распознавания

**Было**

`POST /v1/audio/transcriptions` с моделью, которая отключена или отсутствует в каталоге платформы, отправлял запрос в сервис распознавания, если это модель по умолчанию — в том числе когда поле `model` не передано. Сервис отказывал, и ответом был `502 ai_provider_unavailable` с предложением повторить запрос позже. Повтор не помогал.

**Стало**

Модель без включённой строки в каталоге — в том числе модель по умолчанию, когда поле `model` не передано, — отклоняется с `404 ai_model_not_found` до распознавания, списания нет. Так же `POST /v1/embeddings` отвечает на отключённую модель.

### BC-0930-29: повторное создание сервера в галактике не плодит приложения

> Поддержка старого формата до: не предусмотрена

**Было**

На портале, где новые приложения размещаются в галактике, повторный или параллельный [POST /v1/infra/servers](/docs/infra/servers/create) тем же ключом мог ответить `201` с другим `data.id` и создать ещё одно приложение.

**Стало**

Пока `data.status` galaxy-приложения, созданного тем же ключом, равен `provisioning`, повтор отвечает `201` с тем же `data.id` и `reused: true`. Проигравший параллельный запрос либо получает тот же идентификатор, либо ответ `409 APPLICATION_FIRST_SERVER_IN_PROGRESS`. Второй сервер и второе приложение не создаются. Если соседний запрос с другим `Idempotency-Key` уже начал deploy, переданный повтором `source` не запускает конкурирующую сборку: ответ содержит `sourceIgnored: true`, но не содержит `next`; нужно опрашивать возвращённый сервер до выхода из `provisioning`. Если deploy для существующего приложения ещё не начинался, ответ сохраняет `next: "deploy"`, в том числе когда переданный повтором `source` был проигнорирован. Повтор с тем же `Idempotency-Key` отдельно помнит, принял ли исходный запрос source: активная исходная сборка повторяется как `deploying: true` без `sourceIgnored` и `next` и повторно не запускается. После переноса владельца/карточки или потери рабочего Galaxy-host прежний идентификатор не раскрывается, а ключ остаётся израсходованным. Серверы приложений агентов и ботов этим сценарием не переиспользуются. Политика `SERVER_CREATION_DISABLED` / `SERVER_CREATION_ADMINS_ONLY` по-прежнему запрещает новый ресурс, но не мешает вернуть уже принадлежащий вызывающему id; `INFRA_NOT_PERMITTED` остаётся ранним отказом. Уже запущенное приложение, `placement: "dedicated"` и портал, где раздел «Приложения» выключен, не запрещают следующее создание.

**Что делать интеграторам**

При `reused: true` продолжайте работу с возвращённым `data.id`. Если вместе с `sourceIgnored: true` поля `next` нет, не вызывайте deploy и не создавайте ещё один сервер: опрашивайте `GET /v1/infra/servers/{id}` до выхода из `provisioning`. После завершения раннего deploy отправляйте проигнорированный source отдельным вызовом только если всё ещё намерены заменить результат. Если ответ содержит `next: "deploy"`, для существующего приложения нет активного deploy — отправьте код указанным отдельным вызовом. Поддержка прежней обработки без этого различения не предусмотрена: она могла запустить конкурирующую сборку.

### NEW-0930-30: API ботов предупреждает о регистрации, которую нужно заменить после смены адреса портала

В успешных ответах API появилось опциональное поле `needsReregistration`. Если платформа зафиксировала смену адреса после развёртывания этого изменения, для затронутого бота пустой [GET /v1/bots/:botId/events](/docs/bots/events/polling) и успешный [POST /v1/bots/:botId/resubscribe](/docs/bots/management/resubscribe) возвращают поле со значением `true` и путь восстановления с учётом владельца. Прямое удаление и повторная регистрация разрешены только для самостоятельного Bot; бота AI-агента или управляемого бота нужно восстанавливать через механизм ресурса-владельца или поддержку. При событиях в очереди поле отсутствует. Исторические смены адреса автоматически не отмечаются, поэтому отсутствие поля не исключает более ранний переезд. Статус остаётся HTTP 200.

### BC-0930-31: Отзыв ключа, управляющего сервером вне области владельца и портала

> Поддержка старого формата до: не предусмотрена

**Было**

Отзыв ключа через [PATCH /v1/keys/:id](/docs/management-keys) или [POST /v1/connect/revoke](/docs/partner-connect) мог лишить управления живой сервер другого пользователя, сервер без владельца или сервер того же пользователя на другом портале.

**Стало**

Эти запросы возвращают `409 KEY_MANAGES_FOREIGN_SERVER` до изменения ключа и токенов.

**Что делать интеграторам**

Укажите владельца и нужный портал сервера, затем перепривяжите его к ключу этого владельца в том же портале и повторите отзыв.

### NEW-0930-32: Чаты: стикеры мессенджера v2 — наборы, подключение, удаление и недавние стикеры

В разделе чатов появились [стикеры](/docs/chats/stickers) на методах мессенджера v2 Битрикс24. [GET /v1/chats/stickers/packs](/docs/chats/stickers/packs) отдаёт наборы пользователя страницами: первая страница несёт и недавние стикеры, следующие запрашиваются курсором `lastId` и `lastType`. [GET /v1/chats/stickers/packs/:packId](/docs/chats/stickers/pack-get) возвращает набор со стикерами, `PATCH` того же адреса переименовывает свой набор, `DELETE` удаляет его. [POST /v1/chats/stickers/packs/:packId/link](/docs/chats/stickers/link-create) подключает чужой набор к своему списку, `DELETE` того же адреса отключает его. [DELETE /v1/chats/stickers/packs/:packId/stickers](/docs/chats/stickers/pack-stickers) удаляет стикеры из своего набора, [DELETE /v1/chats/stickers/recent](/docs/chats/stickers/recent) очищает список недавних стикеров, а `DELETE /v1/chats/stickers/recent/:stickerId` убирает из него один стикер. Номера встроенных и пользовательских наборов пересекаются, поэтому операции над набором требуют параметр `packType` — `vendor` или `custom`. Удаление набора, стикеров и очистка недавних необратимы. Первая страница `GET /v1/chats/stickers/packs` также удаляет лишние записи недавних стикеров и потому, как и остальные изменяющие операции, отвечает ключу только для чтения `403 WRITE_BLOCKED_READONLY_KEY`; страницы с курсором остаются чтением. Неизвестный или повторный параметр отклоняется с `400 INVALID_PARAMS`, код отказа Битрикс24 приходит в `error.b24Code`. Создать набор и добавить в него стикеры через API нельзя.

### FIX-0930-33: спецификация PATCH /v1/infra/servers/{id}/access-policy объявляет accessPolicy строкой из перечисления

**Было**

`GET /v1/openapi.json` описывал поле `accessPolicy` в теле `PATCH /v1/infra/servers/{id}/access-policy` как объект. Тело по такой схеме (`{"accessPolicy":{}}`) метод отклонял с `400 VALIDATION_ERROR`.

**Стало**

Спецификация объявляет `accessPolicy` строкой из перечисления `OWNER_ONLY`, `NAMED_USERS`, `DEPARTMENT`, `PORTAL`, `AUTHENTICATED`, `PUBLIC` — ровно тем, что метод принимает, — и описывает ответ `400` (`VALIDATION_ERROR`, `BLACKHOLE_ONLY`). Поведение метода не изменилось: запрос с допустимым значением, как и раньше, получает HTTP 200.

### NEW-0930-34: лента активности сервера

`GET /v1/infra/servers/{id}/activity` отдаёт хронологию сбоев и ключевых событий сервера: паузы и провалы доставки событий портала, проблемы доставки боту, провалы выкладки и команд, пробуждения и смены статуса — новые сверху, постранично через `nextCursor`. У каждой записи машинный `kind` из закрытого списка, а `code` — либо значение из закрытого списка, либо `null`: часть видов событий причину не различает. Нераспознанный код отдаётся как `other`. Повторы за пять минут складываются в одну запись со счётчиком `count`. Подробности выкладки или команды из ленты читаются через `GET /v1/infra/servers/{id}/operations/{operationId}` личным ключом владельца сервера. Лента включается на платформе Вайбкод постепенно: пока она не включена для владельца сервера, оба метода отвечают `404 SERVER_NOT_FOUND`.

### NEW-0930-35: Чаты: личные папки — создание, правка, порядок и состав

Раздел чатов получил запись папок на методах мессенджера v2 Битрикс24. [POST /v1/chats/folders](/docs/chats/management/folders-create) создаёт личную папку и может сразу наполнить её чатами, `GET`, `PATCH` и `DELETE /v1/chats/folders/:folderId` читают, правят и удаляют её, а `PUT /v1/chats/folders/order` задаёт порядок папок. Отдельные чаты добавляет и убирает [POST и DELETE /v1/chats/folders/:folderId/chats](/docs/chats/management/folder-chats), а `PUT /v1/chats/:dialogId/folders` задаёт полный набор папок одного чата. Источники папки «Все» читает и задаёт [GET и PUT /v1/chats/folders/:folderId/sources](/docs/chats/management/folder-sources): эти два метода выходят в обновлении Битрикс24 `im 26.1300.0`, и портал без него отвечает `422 METHOD_NOT_YET_AVAILABLE`. Пустой состав в `PATCH` очищает папку. Поля, у которых умолчание Битрикс24 стёрло бы данные, обязательны: `folderIds` у `PUT /v1/chats/:dialogId/folders` и `sourceCodes` у записи источников. Запись без эффекта, неизвестный параметр и некорректный элемент списка отклоняются с `400 INVALID_PARAMS` до обращения к Битрикс24. Все вызовы, кроме `GET /v1/chats/folders/:folderId`, считаются записью: первый `GET` источников может сохранить состав папки «Все» и старые закрепы. Ключ только для чтения получает на этих вызовах `403 WRITE_BLOCKED_READONLY_KEY`, как описано на странице [прав доступа](/docs/access-rights).

### NEW-0930-36: Чаты: настройки чата — описание, цвет, аватар, права участников и автоудаление сообщений

Десять новых эндпоинтов меняют настройки чата на методах мессенджера v2 Битрикс24. [PUT /v1/chats/:dialogId/description](/docs/chats/management/description) задаёт описание, [PUT /v1/chats/:dialogId/color](/docs/chats/management/color) — цвет одним из семнадцати кодов палитры, [PUT /v1/chats/:dialogId/avatar](/docs/chats/management/avatar) — аватар изображением в base64 или файлом с Диска. Шесть операций [PUT /v1/chats/:dialogId/permissions/…](/docs/chats/management) задают, кто пишет сообщения, приглашает гостей, меняет права, меняет оформление, добавляет и удаляет участников. [PUT /v1/chats/:dialogId/auto-delete](/docs/chats/management/auto-delete) включает автоудаление сообщений с задержкой 1, 24, 168 или 720 часов и выключает его значением `0`. Значение, которое портал молча заменил бы своим, отклоняется до записи с `400 INVALID_PARAMS`: цвет вне палитры, право вне набора операции, строка, которая не читается как изображение. Отказ портала в правах приходит как `403 BITRIX_ACCESS_DENIED`, тело запроса аватара больше 1 МиБ — `413 PAYLOAD_TOO_LARGE`. Ключ только для чтения получает на всех десяти `403 WRITE_BLOCKED_READONLY_KEY`.

### NEW-0930-39: несколько баз 1С на портале: список баз и выбор базы параметром instanceId

Новый эндпоинт [`GET /v1/onec/instances`](/docs/onec/instances) возвращает подключённые к порталу базы 1С: `instanceId`, название и состояние каждой. Нужен скоуп `vibe:onec`, сопоставление с учётной записью 1С не требуется, ключ в режиме «только чтение» обслуживается.

У [`GET /v1/onec/tools`](/docs/onec/tools), [`POST /v1/onec/tools/{method}/call`](/docs/onec/call) и [`GET /v1/onec/operations/{operationId}`](/docs/onec/operation) появился необязательный query-параметр `instanceId` — идентификатор базы из этого списка. Пока к порталу подключена одна база, параметр можно не передавать: запросы без него работают как раньше. Когда баз несколько, запрос каталога или постановка чтения без `instanceId` отвечает `400 ONEC_INSTANCE_REQUIRED` и операцию не создаёт. Неизвестный, чужой, отключённый или не в формате UUID `instanceId` у каталога и вызова отвечает `404 ONEC_NOT_CONNECTED`. Так же отвечает `instanceId` базы, чей ключ подключения перевыпущен, пока модуль не подключился с новым ключом: на это время база пропадает из списка, но участвует в выборе, и запрос без `instanceId` получает `400 ONEC_INSTANCE_REQUIRED`. Чтение операции с таким `instanceId` или с `instanceId` другой базы отвечает `404 ONEC_OPERATION_NOT_FOUND`, а без параметра находит операцию по одному `operationId` при любом числе баз.

### NEW-0930-40: Чаты: ссылки на чат, вступление по коду, гостевые ссылки и приглашения гостей

В разделе чатов появились [ссылки и гости](/docs/chats/sharing) — 11 эндпоинтов для ссылок и приглашений. Сотрудника портала приглашают личной ссылкой на чат: [POST /v1/chats/:dialogId/sharing-links/individual](/docs/chats/sharing/individual-link) выдаёт ссылку с кодом, по коду вступают через [POST /v1/chats/join-by-code](/docs/chats/sharing/join), ссылку читают [GET /v1/chats/sharing-links/:code](/docs/chats/sharing/link-get), перевыпускают через [POST /v1/chats/:dialogId/sharing-links/individual/regenerate](/docs/chats/sharing/individual-link-regenerate) и отзывают через [DELETE /v1/chats/sharing-links/:code](/docs/chats/sharing/link-revoke). Людей вне портала приглашают [гостевой ссылкой](/docs/chats/sharing/guest-link) или персональными приглашениями [по почте](/docs/chats/sharing/invite-email) и [по SMS](/docs/chats/sharing/invite-phone) — до 10 за вызов, итог каждого приглашения приходит в его элементе ответа. Неизвестное поле тела или параметр запроса отклоняется с `400 INVALID_PARAMS`, код отказа портала приходит в `error.b24Code`. Все вызовы, кроме чтения ссылки по коду, изменяющие: ключ только для чтения получает на них `403 WRITE_BLOCKED_READONLY_KEY`. Адреса и телефоны из тела приглашения Вайбкод в своих журналах не сохраняет.

### NEW-0930-41: складские документы и позиции доступны через V1

Добавлены `/v1/catalog-documents` и `/v1/catalog-document-elements` для чтения и записи, а также `POST /v1/catalog-documents/:id/conduct` и `/cancel`. Проведение и отмена требуют ключ с правом записи и возвращают перечитанный статус.

### FIX-0930-42: вызовы внешнего API приложения входят в дневную норму ключа

**Было**

Вызовы `ANY /v1/applications/{id}/api/**` проходили проверку дневной нормы запросов, но в счётчик ключа не попадали: `X-RateLimit-Used` у ключа внешнего API всегда оставался `0`, а `X-RateLimit-Remaining` — равным `X-RateLimit-Quota`.

**Стало**

Когда на портале включён учёт внешнего API приложений, в дневную норму ключа владельца приложения засчитывается вызов, который платформа отправила к приложению и на который пришёл ответ: ответ самого приложения с любым статусом или ответ туннеля к приложению о том, что приложение недоступно, занято или вернуло слишком большой ответ (`503 APP_API_UNAVAILABLE` от туннеля, `502 APP_API_RESPONSE_TOO_LARGE`). `X-RateLimit-Used` растёт, `X-RateLimit-Remaining` уменьшается, счётчик обновляется по закрытым часам, как и у остальных ключей. Вызовы сверх нормы оплачиваются по цене обычного запроса по ключу. Не засчитываются отказы самой платформы: проверки ключа и доступа, перегрузка платформы (тот же код `503 APP_API_UNAVAILABLE`, но без обращения к приложению), `429 QUOTA_EXCEEDED`, `503 APP_API_TIMEOUT`. Не засчитываются и вызовы, сделанные до включения учёта для портала: учёт портала начинается с момента включения, и если сразу после него настройки учёта снова меняли, первые минуты (меньше часа) могут не засчитаться — в пользу клиента. При исчерпанной норме и платной цене запроса на предоплаченном счёте без баланса вызов получает `429 QUOTA_EXCEEDED` — так же, как любой запрос по ключу; в остальных случаях ответ канала остаётся прежним, успешный ответ приложения не меняется.

**Влияние на интеграторов**

Менять ничего не нужно. Учёт включается только на порталах с включённым флагом учёта. Норма и цена запроса по ключу берутся из тарифа портала. Отказ `429 QUOTA_EXCEEDED` возможен только когда норма исчерпана, у услуги ненулевая цена и счёт на предоплате без баланса. Пока цена нулевая, исчерпание нормы видно только по `X-RateLimit-Remaining`, равному 0, — вызовы не отказываются. Ненулевая цена — отдельное решение с собственной записью `BC`. Следите за `X-RateLimit-Remaining` у ключа внешнего API и при предоплате держите на счёте баланс.

### NEW-0930-43: Запись типов цен каталога через API Вайбкод

Для типов цен добавлены `POST /v1/catalog-price-types`, `PATCH /v1/catalog-price-types/:id` и `DELETE /v1/catalog-price-types/:id`. Нужны скоуп `catalog` и право Битрикс24 «Управление типами цен». Удаление небазового типа безвозвратно удаляет все цены товаров этого типа; базовый тип удалить нельзя.

### NEW-0930-44: Чаты: реакции, закреплённые сообщения, пересылка, поиск в чате и индикатор ввода

Раздел сообщений получил девять эндпоинтов для работы с сообщениями и действиями участников. Реакции: [GET /v1/chats/messages/:messageId/reactions](/docs/chats/messages/reactions-list) отдаёт реакции на сообщение с курсором `lastId` и фильтром по коду, [POST /v1/chats/messages/:messageId/reactions](/docs/chats/messages/reactions-create) ставит свою реакцию, а [DELETE /v1/chats/messages/:messageId/reactions/:reaction](/docs/chats/messages/reactions-delete) снимает её. Код реакции задаётся в camelCase (`like`, `faceWithThermometer`). Закреплённые сообщения: [GET /v1/chats/:dialogId/pins](/docs/chats/messages/pins) отдаёт закрепы чата вместе с самими сообщениями, [POST /v1/chats/messages/:messageId/pin](/docs/chats/messages/pins) закрепляет сообщение, а [DELETE /v1/chats/messages/:messageId/pin](/docs/chats/messages/pins) открепляет его. [GET /v1/chats/:dialogId/messages/search](/docs/chats/messages/search) находит сообщения одного чата по подстроке и отдаёт их в форме ленты v2. Запрос короче трёх символов отклоняется с `400 INVALID_PARAMS`, чтобы поиск не возвращал всю ленту вместо совпадений. [POST /v1/chats/:dialogId/forward](/docs/chats/messages/forward) пересылает в чат до 20 сообщений с необязательным комментарием. Ответ сопоставляет клиентский UUID каждого сообщения с ID его копии, а начиная с `im 26.1300` называет и отказы в `failureMap`. [POST /v1/chats/:dialogId/typing](/docs/chats/messages/typing) показывает участникам чата, что пользователь пишет, записывает голосовое или отправляет файл. Список реакций, список закрепов и поиск могут сделать пользователя участником чата, если чат разрешает автовступление. Ключу только для чтения они доступны, если это личный ключ сотрудника и чат уже существует. Остальные ключи только для чтения получают на них `403 WRITE_BLOCKED_READONLY_KEY` — см. [права доступа](/docs/access-rights).

### NEW-0930-45: Чаты: якоря, комментарии канала, блоки сообщения и число закреплённых

Раздел чатов получил десять операций вокруг сообщения на методах мессенджера v2 Битрикс24. [Якоря](/docs/chats/messages/anchors) — отметки непрочитанных упоминаний и реакций — снимаются во всём чате через `POST /v1/chats/:dialogId/anchors/read` или на выбранных сообщениях через `POST /v1/chats/anchors/read`. [Комментарии канала](/docs/chats/messages/comments): `GET /v1/chats/messages/comments` отдаёт сводку веток по постам, `POST /v1/chats/:dialogId/comments/read-all` отмечает прочитанными все комментарии канала, а `POST` и `DELETE /v1/chats/messages/:messageId/comments/subscription` включают и выключают уведомления о новых комментариях к посту. [Блоки сообщения-конструктора](/docs/chats/messages) добавляются, заменяются и удаляются через `POST /v1/chats/messages/:messageId/blocks`, `PATCH` и `DELETE /v1/chats/messages/:messageId/blocks/:blockId`. [Число закреплённых сообщений](/docs/chats/messages/pins) отдаёт `GET /v1/chats/:dialogId/pins/count`. Неверный вход отклоняется с `400 INVALID_PARAMS` до обращения к Битрикс24, код отказа портала приходит в `error.b24Code`. Снятие якорей — изменение, хотя метод Битрикс24 называется `read`: на обоих эндпоинтах ключ только для чтения получает `403 WRITE_BLOCKED_READONLY_KEY`. Число закреплённых может сделать пользователя участником чата с автовступлением. Ключу только для чтения оно доступно, если это личный ключ сотрудника и чат уже существует. Остальные ключи только для чтения получают тот же `403` — см. [права доступа](/docs/access-rights). Сводка комментариев остаётся чтением.

### FIX-0930-46: прежний ответ опроса событий

[GET /v1/chats/events](/docs/chats/events/poll) снова возвращает HTTP 200 с пустой лентой и прежним offset, если Битрикс24 не передал результат. Форма ответа и вызов прежние; новый отказ 502 для этого случая снят.

### FIX-0930-47: прежний переход ленты задачи к легаси

`GET /v1/tasks/{taskId}/chat/messages` снова распознаёт машинный код, содержащий `METHOD_NOT_FOUND`, как отсутствие v2 на портале и переходит к легаси. Прежний кэш и контракт чтения сохранены; READONLY по-прежнему использует легаси-путь.