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

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

### BC-0925-1: нечитаемый номер поля отбивается до изменения и удаления поля смарт-процесса

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

**Было**

[PATCH /v1/items/{entityTypeId}/userfields/{id}](/docs/userfields/smart-processes/update) и [DELETE /v1/items/{entityTypeId}/userfields/{id}](/docs/userfields/smart-processes/delete) принимали в `:id` любую строку. Значение с цифрами в начале молча обрезалось по первому постороннему символу: по `:id` со значением `7abc` изменялось или безвозвратно удалялось поле с номером 7 — другое, чем запрошено, — и ответ был успешным (`{"updated": true}` и `204`). Значение без цифр уходило на портал пустым, и запрос заканчивался ошибкой Битрикс24 о непереданном обязательном параметре.

**Стало**

`:id` обязан быть целым положительным числом в обычной записи: только цифры, без ведущего нуля, знака, дробной части, экспоненты и пробелов, и не больше `9007199254740991`. Иначе платформа Вайбкод отвечает `400 INVALID_PARAMS` и называет параметр в тексте сообщения. Обращения к порталу при таком отказе не происходит, поле не изменяется и не удаляется.

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

Если номер поля берётся из [списка полей смарт-процесса](/docs/userfields/smart-processes/list) и подставляется как есть, менять нечего — такие вызовы работают как раньше.

Отказ теперь получают три класса значений, и различаются они тем, что происходило раньше:

- **раньше менялось или удалялось ЧУЖОЕ поле под кодом успеха** — строка с цифрами в начале и посторонним хвостом (`7abc` читалось как 7), экспонента (`7e2` читалось как 7, а не 700) и номер больше `9007199254740991` (при пересчёте съезжал на соседний). Эти вызовы меняли не то, что вы просили, и молчали об этом;
- **раньше операция шла над ПРАВИЛЬНЫМ полем под кодом успеха** — номер, записанный не в обычной форме: ведущий ноль (`007`), знак (`+7`), дробь (`7.0`), пробелы по краям. Такие вызовы работали верно и теперь получают `400`. Это единственный класс, который правка ломает у исправно работавшей интеграции, — уберите лишние символы, оставив только цифры;
- **раньше приходила ошибка портала** — значение без цифр, в том числе системное имя поля вида `UF_CRM_…`. Теперь платформа Вайбкод отвечает `400` сама, до обращения к порталу.

Во всех трёх случаях подставьте числовой номер поля из списка полей ровно в том виде, в каком он там приходит.

**Затронутые эндпоинты:** [PATCH /v1/items/{entityTypeId}/userfields/{id}](/docs/userfields/smart-processes/update), [DELETE /v1/items/{entityTypeId}/userfields/{id}](/docs/userfields/smart-processes/delete) и их короткие адреса для смарт-счетов `/v1/userfields/invoices/{id}`.

### FIX-0925-3: вход из Коворка открывает и приложения Galaxy

**Было**

`POST /v1/cowork/app-login` выдавал вход только в приложение на отдельном сервере. На адрес приложения Galaxy он отвечал `404 APP_NOT_AVAILABLE`, даже когда политика доступа пускала владельца ключа.

**Стало**

Приложение Galaxy проходит ту же проверку доступа, что и приложение на отдельном сервере, и при допуске получает ответ HTTP 200 с адресом входа. Машина-хост Galaxy по-прежнему отвечает `404 APP_NOT_AVAILABLE`: это не приложение.

### FIX-0925-4: сервер, чьё создание сорвалось на стороне облака, больше не висит в `PROVISIONING`

**Было**

Когда облако отказывало уже после начала создания, а запрос шёл с заголовком `Idempotency-Key`,
сервер оставался в статусе `PROVISIONING` без идентификатора облачной машины. Повтор с тем же
ключом возвращал ту же запись, и она навсегда выглядела как «ещё создаётся»: `GET /v1/infra/servers/:id`
отдавал `status: "PROVISIONING"`, хотя создание уже провалилось.

**Стало**

Такой сервер сразу получает `status: "ERROR"`. Ответ на само создание не изменился — это по-прежнему
`502 PROVIDER_ERROR` с прежним текстом, и повтор с тем же `Idempotency-Key` по-прежнему возвращает ту
же запись, а не создаёт вторую машину. Изменился только статус в записи: он честно называет исход,
и такой сервер виден среди неисправных, а не среди создающихся.

### FIX-0925-5: чтение логов спящего приложения не называет адрес пробуждения, который запрещён на хосте

**Было**

[GET /v1/infra/servers/{id}/logs](/docs/infra/deploy/logs) у спящего Galaxy-приложения выдавал `recovery.recoveryAction` с адресом пробуждения всякий раз, когда вызывающему не отказывала ни одна дверь по его ключу. Запрет пробуждения на самом хосте галактики (подписка или тариф, блокировка хоста) в этот признак не входил вовсе, поэтому полноправный владелец получал машинный адрес, звал его и получал `402` либо `403 SERVER_WAKE_BLOCKED`. Тем же признаком выдавалось поле `recovery.deliveryWakesHost` — платный второй путь подъёма, который на заблокированном хосте тоже не срабатывает.

**Стало**

При запрете пробуждения на хосте ответ не называет адрес пробуждения ни одним полем — ни `recovery.recoveryAction`, ни текстом `hint`, — и не называет `recovery.deliveryWakesHost`. Вместо адреса `hint` называет условие: запрет стоит на общем хосте, снимает его владелец аккаунта, и смена ключа не поможет. Сам ответ чтения логов остаётся HTTP 200 с пустым списком строк, как и прежде. Поле `recovery.wakeSchedule` в этом состоянии не меняется: создание окна по расписанию остаётся доступным, и проза отдельно предупреждает, что хост окно не поднимет.

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

Менять ничего не нужно, если вы уже ветвитесь по НАЛИЧИЮ поля `recovery.recoveryAction`, как того требует документация. Клиент, подставлявший адрес пробуждения безусловно, перестанет получать гарантированный отказ по нему.

### FIX-0925-8: загрузка файла ботом проверяет обязательные поля до вызова Битрикс24

**Было**

[POST /v1/bots/:botId/files](/docs/bots/files/upload) передавал тело в Битрикс24 как есть. Если `dialogId` отсутствовал или файл был прислан под нераспознанными именами полей (например, `fileName` и `fileContent`), запрос уходил в Битрикс24 без обязательных параметров, и оттуда возвращался код `100` — «не передан обязательный параметр», без указания, какой именно.

**Стало**

Обязательные поля проверяются до обращения к Битрикс24. Без `dialogId`, имени или содержимого файла ответ — `400 MISSING_PARAMS`. В тексте ошибки перечислены нераспознанные поля тела и показана правильная форма запроса.

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

Корректный запрос в любом из трёх поддерживаемых форматов тела работает как прежде. Клиент, который получал `100`, теперь видит адресный отказ платформы Вайбкод и знает, какое поле пропущено.

### FIX-0925-9: Правка прав ключа, чей вебхук остался на прежнем адресе портала, отвечает PORTAL_ADDRESS_CHANGED

**Было**

[PATCH /v1/keys/:id](/docs/management-keys) с новым списком `scopes` для ключа, чей вебхук после смены адреса портала остался выписан на прежний адрес, отвечал одним из отказов синхронизации прав — `410 STALE_DEVELOPER_KEY`, `502 RECOVERY_FAILED` или `502 DEVKEY_SCOPE_SYNC_FAILED`. Ни один из них не называл настоящую причину: повтор не помогал, а совет переподключить аккаунт этот случай не лечил. Любой вызов такого ключа к порталу при этом уже отвечал `409 PORTAL_ADDRESS_CHANGED`.

**Стало**

Правка прав такого ключа отвечает тем же `409 PORTAL_ADDRESS_CHANGED` и к порталу не обращается. Права ключа не меняются ни на платформе Вайбкод, ни в Битрикс24. Остальные ответы правки прав прежние.

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

Обработайте `409 PORTAL_ADDRESS_CHANGED` так же, как на остальных вызовах ключа: переподключите ключ — вебхук перевыпустится на текущий адрес портала, — затем повторите правку прав. Описание кода — [Авторизация, ключи и права](/docs/errors/auth).

### FIX-0925-10: список бизнес-процессов на портале без модуля отвечает понятным кодом

**Было**

Если модуль бизнес-процессов не входит в тариф портала или выключен в его настройках, Битрикс24 отвечает на метод `bizproc.workflow.instances` сообщением «метод не найден». Запрос [GET /v1/workflows](/docs/automation/workflows/list) отдавал это как `404 ENTITY_NOT_FOUND` — сообщение о ненайденной сущности там, где в порядке и сущность, и сам запрос. Кода `ENTITY_NOT_FOUND` не было в таблице ошибок страницы, а причина отказа по ответу не читалась.

**Стало**

То же состояние портала отвечает `409 BIZPROC_MODULE_NOT_ENABLED`. Сообщение называет обе возможные причины и действие: попросить администратора портала включить бизнес-процессы. Ответ остаётся клиентским отказом класса 4xx, а защита от циклов ошибок такой отказ не считает — он остаётся понятным при любом числе повторов, а не подменяется на `429 ERROR_LOOP_DETECTED`.

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

Действий не требуется: как был отказ 4xx, так и остался. Интеграция, которая отличала выключённый модуль по тексту сообщения Битрикс24, может перейти на код `409 BIZPROC_MODULE_NOT_ENABLED`. Прежний `404 ENTITY_NOT_FOUND` для этого состояния документацией не обещался. Остальные операции раздела «Бизнес-процессы» отвечают как прежде — изменение касается только списка запущенных процессов.

### FIX-0925-11: BitrixGPT 5.5 принимает json_schema, если модель поддерживает structured outputs

**Было**

[POST /v1/chat/completions](/docs/ai/chat/completions) с `response_format.type = json_schema` и моделью `bitrix/bitrixgpt-5.5` отвечал `400` `model_does_not_support_structured_outputs`, а [GET /v1/me](/docs/keys-auth/me) не показывал доступные structured outputs.

**Стало**

Модели BitrixGPT 5.5 и Thinking, поддерживающие structured outputs, появляются в [GET /v1/me](/docs/keys-auth/me), а запросы с `json_schema` проходят проверку возможностей. Клиентам не требуется менять формат запроса.

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

Изменений в интеграционном коде не требуется: используйте прежний `response_format.type = json_schema`.

### FIX-0925-12: хранилище: чтение и удаление по ключу берут неудалённую копию файла

**Было**

Если под одним ключом лежало несколько копий файла и самая ранняя из них была удалена, [GET /v1/storage/objects/{key}](/docs/storage/objects/get), [HEAD /v1/storage/objects/{key}](/docs/storage/objects/head) и [DELETE /v1/storage/objects/{key}](/docs/storage/objects/delete) отвечали `410 STORAGE_OBJECT_DELETED`, хотя файл оставался в [списке объектов](/docs/storage/objects/list). После первого удаления по такому ключу каждый следующий DELETE отвечал так же, а оставшаяся копия не удалялась.

**Стало**

Запрос по ключу берёт самую раннюю неудалённую копию этого файла. Пока такая копия есть, файл читается и удаляется по ключу, и каждый DELETE удаляет одну копию. Когда неудалённых копий не осталось, ответ прежний: `410 STORAGE_OBJECT_DELETED`.

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

Менять ничего не нужно. Для файла с несколькими копиями повторный DELETE по ключу удаляет следующую копию и отвечает `410 STORAGE_OBJECT_DELETED`, только когда копий не осталось.

### BC-0925-13: список почтовых ящиков без модуля «Почта» отвечает понятным 409

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

**Было**

Если на портале нет модуля «Почта», метод не входит в тариф либо портал ещё не получил обновление с `mail.mailbox.list`, Битрикс24 отвечал «метод не найден», и на [GET /v1/mail/mailboxes](/docs/mail/mailboxes/list) это приезжало как `404 ENTITY_NOT_FOUND`. Состояние портала было неотличимо от отсутствующей записи.

**Стало**

Только `GET /v1/mail/mailboxes` отвечает `409 MAIL_MODULE_NOT_ENABLED`. В тексте названы возможные причины — модуль не установлен, метод не входит в тариф либо на портал ещё не приехало обновление с `mail.mailbox.list`, — потому что снаружи их не различить. Прочие отказы Битрикс24 на этом маршруте не изменились: отказ по правам остаётся `403`, лимит запросов — `429` со своим `Retry-After`.

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

Успешные ответы не изменились. Если код ветвился на `404` для списка ящиков, добавьте ветку `409 MAIL_MODULE_NOT_ENABLED`. Не повторяйте неизменный `409` вслепую; повторите запрос после подтверждённого включения модуля, изменения тарифа или обновления портала. Соседние маршруты почтовых ящиков изменение не затрагивает.

### BC-0925-14: лента чата задачи для ключа только для чтения — страница не больше 50 сообщений

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

**Было**

[GET /v1/tasks/:taskId/chat/messages](/docs/entities/tasks/chat) мог отдать любому ключу, в том числе ключу только для чтения, страницу до 200 сообщений — столько, сколько передано в `limit`.

**Стало**

Для ключа только для чтения страница ленты чата задачи — не больше 50 сообщений при любом `limit`: чтение страницей до 200 сообщений может сделать пользователя участником чата задачи, то есть изменяет данные портала, а ключ только для чтения данные портала не меняет. `hasNextPage` для такого ключа вычисляется по заполненности страницы: полная страница означает, что история может продолжаться. Ответ остаётся HTTP 200 той же формы. Ключ с правом записи читает ленту как прежде, до 200 сообщений на страницу.

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

Если ключ только для чтения запрашивает `limit` больше 50, листайте историю курсором `lastId` до `hasNextPage: false` и не рассчитывайте, что страница вместит весь `limit`. Чтобы получать до 200 сообщений на страницу, переключите ключ в режим записи, как описано на странице [прав доступа](/docs/access-rights).

### NEW-0925-15: Чаты: режим format=v2, загрузка чата, счётчики и сообщения вокруг сообщения

Раздел чатов получил режим `format=v2` у двух эндпоинтов и три новых эндпоинта. [GET /v1/chats/recent](/docs/chats/discovery/recent) с параметром `format=v2` отдаёт список последних диалогов страницами по курсору `lastMessageDate` и признаку `hasNextPage`, а [GET /v1/chats/:dialogId/messages](/docs/chats/messages/list) с тем же параметром читает ленту по курсору `lastId` в обе стороны через `order`. Без `format=v2` оба эндпоинта отвечают как раньше. Новые эндпоинты [GET /v1/chats/:dialogId/load](/docs/chats/messages/load) открывают чат одним запросом — карточка, первая страница сообщений и закреплённые, [GET /v1/chats/counters](/docs/chats/discovery/counters) отдаёт счётчики непрочитанного по чатам, а [GET /v1/chats/messages/:messageId/context](/docs/chats/messages/context) — сообщение вместе с соседними. Лимиты вне диапазона обрезаются с эхом в `meta`, неизвестный или повторный параметр, кроме `format`, отклоняется с `400 INVALID_PARAMS`; при повторе `format` берётся последнее значение. Форма `format[]=v2` тоже принимается, если все элементы равны `v2`. Код отказа портала приходит в `error.b24Code` у ответов `422` и `404`. Дата, которой нет в календаре (`2026-02-30`, `24:00`), в курсоре `lastMessageDate` и в `updatedAfter` отклоняется с `400 INVALID_PARAMS`, а не сдвигается на соседний день. Открытие чата, сообщения вокруг сообщения и лента в режиме v2 могут сделать пользователя участником чата, если чат разрешает автовступление, поэтому они считаются изменяющими: ключ только для чтения получает на них `403 WRITE_BLOCKED_READONLY_KEY`, как описано на странице [прав доступа](/docs/access-rights).

### FIX-0925-16: обрыв связи с порталом отвечает 502 BITRIX_UNAVAILABLE

**Было**

Если соединение с порталом Битрикс24 обрывалось до ответа (сброс или отказ соединения, сбой TLS, обрыв посреди ответа), запрос к данным портала получал `500 INTERNAL_ERROR`, как будто сломалась сама платформа. Так же отвечал и [POST /v1/batch](/docs/batch).

**Стало**

Такой обрыв отвечает `502 BITRIX_UNAVAILABLE`, как и описано в [справочнике ошибок](/docs/errors/platform). В `error.message` указан машинный код причины, если он известен, например `ECONNRESET`, в `error.hint` — правило повтора: чтение можно повторить с паузой, а перед повтором записи перечитайте запись. Сам запрос платформа не повторяет.

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

Действий не требуется. Если вы повторяете запрос с паузой на `BITRIX_UNAVAILABLE`, короткие сетевые сбои теперь попадают в эту ветку, а не в `INTERNAL_ERROR`.

### FIX-0925-18: будильник на сервере с режимом работы по расписанию заводится и правится через API

**Было**

Запись FIX-0916-10 обещала, что сервер в режиме работы `SCHEDULE` не считается круглосуточным и дополнительный будильник на нём заводится обычным порядком. Через API обещание не выполнялось: [POST /v1/infra/servers/{id}/wake-schedules](/docs/infra/wake-schedules/create) и [PATCH /v1/infra/servers/{id}/wake-schedules/{scheduleId}](/docs/infra/wake-schedules/update) отвечали `400 ALWAYS_ON_CONFLICT` такому серверу на невытесняемом тарифе без порога засыпания — и ключу владельца, и ключу администратора команды сервера.

**Стало**

Сервер в режиме работы `SCHEDULE` получает будильник через API обычным порядком: создание отвечает `201`, правка — `200`, как и у любого сервера, которому окно разрешено. Серверу в режиме работы `ALWAYS` на невытесняемом тарифе отказ `400 ALWAYS_ON_CONFLICT` приходит по-прежнему, кроме приложения в галактике: тариф оно наследует от галактики и круглосуточным не считается.

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

Менять ничего не нужно.

### FIX-0925-19: справочник сотрудников использует доступные ключи

`GET /v1/infra/servers/:id/b24-users` находит сотрудников, даже если у ключа сервера нет прав на справочник.

**Было**

Если у ключа сервера не было права `user`, Битрикс24 отказывал, и ответ приходил пустым: `{ "success": true, "data": [] }` — без объяснения причины.

**Стало**

Если ключ сервера получил отказ по правам, Вайбкод пробует другие ключи того же портала: запасной ключ сервера, затем ключи действующих администраторов портала. Если права на справочник не нашлись ни у одного ключа, ответ остаётся HTTP 200 с пустым `data` и содержит `hint` с объяснением, какие права выдать. При сетевой ошибке ответ прежний: HTTP 200 и `{ "success": true, "data": [] }`.

### BC-0925-20: события портала и колбэки роботов приходят без токенов Битрикс24 при ключе «Только чтение»

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

**Было**

Сервер на платформе Вайбкод получал события портала и колбэки роботов бизнес-процессов с `auth[access_token]` и `auth[refresh_token]` при любом режиме ключей.

**Стало**

Если ключ сервера или ключ авторизации подписанного приложения в режиме «Только чтение», событие и колбэк приходят без `auth[access_token]` и `auth[refresh_token]`, и шлюз не добавляет к ним заголовки пользователя события. Так же приходят события серверу, чей ключ удалён или отозван, и приложению без активного ключа авторизации. Событие на адрес приложения вне платформы — не субдомен Black Hole и не собственный домен сервера — приходит без этих токенов при любом режиме ключей. `auth[application_token]`, `auth[user_id]` и данные события остаются. Обмен токена события на сессию через `POST /v1/oauth/placement-session` такому обработчику недоступен, а робот, ждущий ответа, не завершится: ответ роботу — запись в Битрикс24. Если адрес приложения указывает на сервер платформы, событие пользователя, которому политика доступа этого сервера закрыта, не доставляется; событие на внешний адрес политикой доступа не фильтруется.

Что делать: для чтения вызывайте API Вайбкод своим ключом — вызовы пойдут от владельца ключа. Чтобы вернуть токены и ответы роботам, переведите в «Чтение и запись» оба ключа — ключ сервера и ключ приложения. Если адрес приложения внешний, перенесите обработчик на сервер платформы: туда токены приходят, когда оба ключа в «Чтение и запись».

### BC-0925-21: выкладка ключом «Только чтение» не публикует анонс новой версии

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

**Было**

`POST /v1/infra/servers/:id/deploy` с полем `changelog` публиковал текст новой версии подписчикам в ленту канала приложения в мессенджере Битрикс24 при любом режиме ключа.

**Стало**

Выкладка ключом в режиме «Только чтение» анонс не публикует: публикация в ленту — запись в Битрикс24. Заметка версии сохраняется в хранилище исходников, карточка каталога и иконка публикуются, в `warnings` ответа приходит предупреждение. Ответ HTTP 200 не меняется.

Что делать: чтобы анонс публиковался, выкладывайте ключом в режиме «Чтение и запись».

### NEW-0925-22: поле `note` в блоке `eventDelivery` ответа `GET /v1/me`

В блоке `eventDelivery` ответа `GET /v1/me` появилось поле `note`. Оно объясняет, при каком режиме ключей события и колбэки приходят без `auth[access_token]` и `auth[refresh_token]`, что из этого следует и как вернуть токены. Поле приходит всегда, когда в ответе есть блок `eventDelivery`, независимо от режима ключа, которым вызван `GET /v1/me`.