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

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

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

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

Было

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

Стало

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

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

Если номер поля берётся из списка полей смарт-процесса и подставляется как есть, менять нечего — такие вызовы работают как раньше.

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

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

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

Затронутые эндпоинты: PATCH /v1/items/{entityTypeId}/userfields/{id}, DELETE /v1/items/{entityTypeId}/userfields/{id} и их короткие адреса для смарт-счетов /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 у спящего 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 передавал тело в Битрикс24 как есть. Если dialogId отсутствовал или файл был прислан под нераспознанными именами полей (например, fileName и fileContent), запрос уходил в Битрикс24 без обязательных параметров, и оттуда возвращался код 100 — «не передан обязательный параметр», без указания, какой именно.

Стало

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

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

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

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

Было

PATCH /v1/keys/:id с новым списком 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 так же, как на остальных вызовах ключа: переподключите ключ — вебхук перевыпустится на текущий адрес портала, — затем повторите правку прав. Описание кода — Авторизация, ключи и права.

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

Было

Если модуль бизнес-процессов не входит в тариф портала или выключен в его настройках, Битрикс24 отвечает на метод bizproc.workflow.instances сообщением «метод не найден». Запрос GET /v1/workflows отдавал это как 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 с response_format.type = json_schema и моделью bitrix/bitrixgpt-5.5 отвечал 400 model_does_not_support_structured_outputs, а GET /v1/me не показывал доступные structured outputs.

Стало

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

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

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

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

Было

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

Стало

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

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

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

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

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

Было

Если на портале нет модуля «Почта», метод не входит в тариф либо портал ещё не получил обновление с mail.mailbox.list, Битрикс24 отвечал «метод не найден», и на GET /v1/mail/mailboxes это приезжало как 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 мог отдать любому ключу, в том числе ключу только для чтения, страницу до 200 сообщений — столько, сколько передано в limit.

Стало

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

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

Если ключ только для чтения запрашивает limit больше 50, листайте историю курсором lastId до hasNextPage: false и не рассчитывайте, что страница вместит весь limit. Чтобы получать до 200 сообщений на страницу, переключите ключ в режим записи, как описано на странице прав доступа.

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

Раздел чатов получил режим format=v2 у двух эндпоинтов и три новых эндпоинта. GET /v1/chats/recent с параметром format=v2 отдаёт список последних диалогов страницами по курсору lastMessageDate и признаку hasNextPage, а GET /v1/chats/:dialogId/messages с тем же параметром читает ленту по курсору lastId в обе стороны через order. Без format=v2 оба эндпоинта отвечают как раньше. Новые эндпоинты GET /v1/chats/:dialogId/load открывают чат одним запросом — карточка, первая страница сообщений и закреплённые, GET /v1/chats/counters отдаёт счётчики непрочитанного по чатам, а GET /v1/chats/messages/:messageId/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, как описано на странице прав доступа.

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

Было

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

Стало

Такой обрыв отвечает 502 BITRIX_UNAVAILABLE, как и описано в справочнике ошибок. В 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 и PATCH /v1/infra/servers/{id}/wake-schedules/{scheduleId} отвечали 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.