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

← Журнал изменений · Сентябрь 2026

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

В разделе чатов появились настройки мессенджера и служебные методы на методах мессенджера v2 Битрикс24. GET /v1/chats/settings читает общие настройки пользователя, PATCH того же адреса меняет одну настройку, а PUT /v1/chats/settings/status устанавливает статус — online, dnd или away. Без userId операции работают с настройками владельца ключа, чужие настройки доступны только администратору Битрикс24. GET /v1/chats/:dialogId/task-form и POST /v1/chats/messages/:messageId/task-form отдают данные формы создания задачи из чата и из сообщения, а GET /v1/chats/:dialogId/flow-form — формы потока коллаба. POST /v1/chats/:dialogId/bot-context передаёт контекст ботам чата, а POST /v1/chats/:dialogId/zoom создаёт конференцию Zoom с приглашением в чат. GET /v1/chats/state отдаёт состояние обновлений и счётчики, GET /v1/chats/tariff-restrictions — ограничения тарифа, GET /v1/chats/promotions — активные промо-подсказки, GET /v1/chats/users/:userId/department — отдел пользователя. POST /v1/chats/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 ставят и снимают метку «непрочитано» на строке чата в списке последних диалогов, а POST /v1/chats/messages/:messageId/mark отмечает сообщение, с которого чат откроется в следующий раз, — «прочитать позже»; снимается он тем же DELETE. GET /v1/chats/:dialogId/users/mentionable отдаёт участников чата, которых можно упомянуть через @, а GET /v1/chats/:dialogId/users/membership проверяет, кто из переданных пользователей состоит в чате. GET /v1/chats/folders возвращает папки чатов пользователя — системные разделы мессенджера и личные папки, а GET /v1/chats/folders/:folderId/recent — список чатов одной папки страницами по курсору lastMessageDate. Неизвестный или повторный параметр отклоняется с 400 INVALID_PARAMS, код отказа Битрикс24 приходит в error.b24Code. Метка и «прочитать позже» остаются изменяющими вызовами и получают 403 WRITE_BLOCKED_READONLY_KEY с ключом только для чтения. Упоминания и проверка участия доступны обычному личному ключу сотрудника только для существующего чата по контракту прав доступа; в чате, допускающем автовступление, они могут сделать пользователя участником; GET /v1/chats/folders также блокируется: портал может создать папки и перенести закрепления; список чатов уже известной папки остаётся чтением.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

POST /v1/chats/:chatId/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 возвращают исходный 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 с параметром format=v2 отмечает прочитанными ровно названные уведомления — тело { "ids": [...] }, до 100 идентификаторов, ответ { counter, viewedMessages }; без format=v2 эндпоинт отвечает как раньше. POST /v1/notifications/read-all отмечает прочитанными все уведомления, кроме перечисленных в excludeIds. DELETE /v1/notifications необратимо удаляет все уведомления владельца ключа и принимает только голый адрес: любой параметр запроса или поле тела отклоняется с 400 INVALID_PARAMS. Группы уведомлений читаются, создаются, переименовываются и удаляются через /v1/notifications/groups, условия группы — через /v1/notifications/groups/:groupId/conditions; удаление последнего условия удаляет и группу. GET /v1/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 с search_depth: "advanced" выполняется в режиме basic, и запрос не отклоняется. В ответе и в событиях SSE start и done приходит search_depth: "basic", списание идёт по цене basic, а в заголовках ответа появляется X-Search-Depth-Downgraded: advanced.

Перед платным запросом уже учтённый расход портала за сутки по московскому времени складывается со стоимостью этого запроса. Если сумма превысит потолок, POST /v1/search и POST /v1/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 отдавал ошибку Битрикс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}, DELETE /v1/posts/{id} и POST /v1/posts/{id}/share при отказе Битрикс24 с кодами 404 POST_NOT_FOUND, 400 INVALID_POST_ID и 400 INVALID_RECIPIENTS отдавали в error.message текст портала как есть. Так же отвечали POST /v1/posts/{id}/comments и DELETE /v1/posts/{id}/comments/{commentId} на отказ с кодом 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} — 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 отдаёт первую страницу чата — вокруг отметки непрочитанного или последнего прочитанного сообщения, GET /v1/chats/messages/:messageId/viewers — кто и когда просмотрел сообщение, страницами по курсору lastId. POST /v1/chats/messages/:messageId/disappear ставит сообщению таймер удаления, POST /v1/chats/messages/:messageId/inform доставляет его собеседнику в режиме «Не беспокоить» как важное уведомление, DELETE /v1/chats/messages/:messageId/url-preview убирает превью ссылки, а POST /v1/chats/messages/read отмечает прочитанными выбранные сообщения — от 1 до 100 за запрос. Отправка, редактирование, удаление и отметка чата прочитанным получили режим format=v2: правка меняет не только текст, но и вложения, клавиатуру, меню и блоки, а правка и удаление проверяют, что сообщение лежит в диалоге из пути, и иначе отвечают 404 ENTITY_NOT_FOUND, ничего не меняя. Без format=v2 эти эндпоинты отвечают как раньше. Неверный вход отклоняется с 400 INVALID_PARAMS до обращения к Битрикс24, код отказа портала приходит в error.b24Code. Первая страница и просмотры могут сделать пользователя участником чата с автовступлением, поэтому ключ только для чтения получает на них 403 WRITE_BLOCKED_READONLY_KEY, как описано на странице прав доступа.

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

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

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

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

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

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

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

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

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

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

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

GET /v1/chats/messages/{messageId}/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 тем же ключом мог ответить 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 и успешный POST /v1/bots/:botId/resubscribe возвращают поле со значением true и путь восстановления с учётом владельца. Прямое удаление и повторная регистрация разрешены только для самостоятельного Bot; бота AI-агента или управляемого бота нужно восстанавливать через механизм ресурса-владельца или поддержку. При событиях в очереди поле отсутствует. Исторические смены адреса автоматически не отмечаются, поэтому отсутствие поля не исключает более ранний переезд. Статус остаётся HTTP 200.

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

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

Было

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

Стало

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

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

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

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

В разделе чатов появились стикеры на методах мессенджера v2 Битрикс24. GET /v1/chats/stickers/packs отдаёт наборы пользователя страницами: первая страница несёт и недавние стикеры, следующие запрашиваются курсором lastId и lastType. GET /v1/chats/stickers/packs/:packId возвращает набор со стикерами, PATCH того же адреса переименовывает свой набор, DELETE удаляет его. POST /v1/chats/stickers/packs/:packId/link подключает чужой набор к своему списку, DELETE того же адреса отключает его. DELETE /v1/chats/stickers/packs/:packId/stickers удаляет стикеры из своего набора, DELETE /v1/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 создаёт личную папку и может сразу наполнить её чатами, GET, PATCH и DELETE /v1/chats/folders/:folderId читают, правят и удаляют её, а PUT /v1/chats/folders/order задаёт порядок папок. Отдельные чаты добавляет и убирает POST и DELETE /v1/chats/folders/:folderId/chats, а PUT /v1/chats/:dialogId/folders задаёт полный набор папок одного чата. Источники папки «Все» читает и задаёт GET и PUT /v1/chats/folders/:folderId/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, как описано на странице прав доступа.

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

Десять новых эндпоинтов меняют настройки чата на методах мессенджера v2 Битрикс24. PUT /v1/chats/:dialogId/description задаёт описание, PUT /v1/chats/:dialogId/color — цвет одним из семнадцати кодов палитры, PUT /v1/chats/:dialogId/avatar — аватар изображением в base64 или файлом с Диска. Шесть операций PUT /v1/chats/:dialogId/permissions/… задают, кто пишет сообщения, приглашает гостей, меняет права, меняет оформление, добавляет и удаляет участников. PUT /v1/chats/:dialogId/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 возвращает подключённые к порталу базы 1С: instanceId, название и состояние каждой. Нужен скоуп vibe:onec, сопоставление с учётной записью 1С не требуется, ключ в режиме «только чтение» обслуживается.

У GET /v1/onec/tools, POST /v1/onec/tools/{method}/call и GET /v1/onec/operations/{operationId} появился необязательный 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: Чаты: ссылки на чат, вступление по коду, гостевые ссылки и приглашения гостей

В разделе чатов появились ссылки и гости — 11 эндпоинтов для ссылок и приглашений. Сотрудника портала приглашают личной ссылкой на чат: POST /v1/chats/:dialogId/sharing-links/individual выдаёт ссылку с кодом, по коду вступают через POST /v1/chats/join-by-code, ссылку читают GET /v1/chats/sharing-links/:code, перевыпускают через POST /v1/chats/:dialogId/sharing-links/individual/regenerate и отзывают через DELETE /v1/chats/sharing-links/:code. Людей вне портала приглашают гостевой ссылкой или персональными приглашениями по почте и по SMS — до 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 отдаёт реакции на сообщение с курсором lastId и фильтром по коду, POST /v1/chats/messages/:messageId/reactions ставит свою реакцию, а DELETE /v1/chats/messages/:messageId/reactions/:reaction снимает её. Код реакции задаётся в camelCase (like, faceWithThermometer). Закреплённые сообщения: GET /v1/chats/:dialogId/pins отдаёт закрепы чата вместе с самими сообщениями, POST /v1/chats/messages/:messageId/pin закрепляет сообщение, а DELETE /v1/chats/messages/:messageId/pin открепляет его. GET /v1/chats/:dialogId/messages/search находит сообщения одного чата по подстроке и отдаёт их в форме ленты v2. Запрос короче трёх символов отклоняется с 400 INVALID_PARAMS, чтобы поиск не возвращал всю ленту вместо совпадений. POST /v1/chats/:dialogId/forward пересылает в чат до 20 сообщений с необязательным комментарием. Ответ сопоставляет клиентский UUID каждого сообщения с ID его копии, а начиная с im 26.1300 называет и отказы в failureMap. POST /v1/chats/:dialogId/typing показывает участникам чата, что пользователь пишет, записывает голосовое или отправляет файл. Список реакций, список закрепов и поиск могут сделать пользователя участником чата, если чат разрешает автовступление. Ключу только для чтения они доступны, если это личный ключ сотрудника и чат уже существует. Остальные ключи только для чтения получают на них 403 WRITE_BLOCKED_READONLY_KEY — см. права доступа.

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

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

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

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

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

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