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

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

NEW-0928-1: результаты задач через старый REST

На платформе Вайбкод появились четыре маршрута для результатов задач: создание из старого комментария, список, первый и последний результат. Они вызывают методы tasks.Task.Result.* и возвращают результат Bitrix24 без изменения. Пустой список остаётся [], а отсутствие первого или последнего результата — { "result": 0 }. Создание из комментария относится только к старым комментариям форума; новая карточка задачи не обещана.

NEW-0928-2: результаты задач через REST 3.0

API Вайбкод добавляет четыре маршрута для создания результата задачи, создания из сообщения чата, обновления и удаления. Они вызывают методы REST 3.0 Битрикс24 и сохраняют их ответ внутри data. Для всех маршрутов нужен скоуп task или tasks и право на запись.

Затронутые эндпоинты: POST /v1/task-results, POST /v1/task-results/from-chat-message, PATCH /v1/task-results/:id, DELETE /v1/task-results/:id. Справка по результатам задач.

NEW-0928-3: Четыре метода шаблонов задач

Через API Вайбкод доступны чтение, список, добавление и изменение шаблонов задач. POST /v1/task-templates вызывает tasks.Template.add и возвращает ID. Список сохраняет форму task_templates и сведения о следующей странице.

NEW-0928-4: 12 операций Scrum доступны через именованные маршруты

Добавлены маршруты /v1/scrum/backlogs, удаление эпика и этапа, создание, изменение, удаление, запуск и завершение спринта, а также добавление и удаление задачи на доске. Каждый маршрут вызывает соответствующий метод Bitrix24 и возвращает его результат в data. Завершение активного спринта принимает ID группы. Прежние успешные ответы остаются успешными без изменения.

FIX-0928-5: создание пользовательского поля проверяет то значение, что уходит в Битрикс24

Было

POST /v1/userfields/users и POST /v1/items/{entityTypeId}/userfields (вместе с POST /v1/userfields/invoices) проверяли обязательные поля по первому написанию ключа в теле. Если в теле были оба написания — userTypeId и USER_TYPE_ID (для полей сотрудников также fieldName и FIELD_NAME), — проверку проходило одно значение, а в Битрикс24 уходило другое. Пустое значение доезжало до портала, и ответ приходил как 422 BITRIX_ERROR с b24Code: "0", по которому не понять, что не так с запросом.

Стало

Проверяется значение, которое реально уходит в Битрикс24: при двух написаниях одного ключа действует последнее в теле, как и в POST /v1/userfields/{entity}. Пустое или отсутствующее значение отклоняется до обращения к порталу ответом 400 MISSING_FIELD. Для смарт-процессов и счетов в Битрикс24 уходит один ключ userTypeId, даже если в теле передан USER_TYPE_ID. Запросы с одним написанием ключа работают как раньше.

FIX-0928-6: повторный `POST /v1/bots` для существующего бота больше не ломает ему токен

Было

Повторный POST /v1/bots с code уже зарегистрированного бота отвечал 201, но после этого бот переставал работать: вызовы /v1/bots/{botId}/* отбивались ошибкой авторизации, а входящие вебхуки бота не доходили. Портал оставлял боту прежние учётные данные, а у себя мы сохраняли новые, которые портал не принимал.

Стало

Если портал вернул тот же botId, сохраняются прежние учётные данные бота, и он продолжает работать. Ответ 201 и его форма не изменились.

BC-0928-7: отказ `agent_turn_loop_detected` для зациклившегося хода агента включается

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

Было

Код отказа agent_turn_loop_detected (409) у POST /v1/chat/completions был объявлен, но не действовал: запрос, в котором после последнего сообщения с ролью user накопилось много ответов модели без tool_calls, обслуживался как обычно.

Стало

Отказ действует. Если в messages после последнего сообщения с ролью user накопилось 20 и более ответов модели с ролью assistant без tool_calls, запрос получает 409 с кодом agent_turn_loop_detected, обращение к модели не выполняется и лимит не расходуется. Порог поднят с объявленных ранее 15 до 20. Ответы с tool_calls в счёт по-прежнему не входят, поэтому ход, в котором модель на каждом шаге вызывает инструменты, условие не задевает. Окно поддержки прежнего поведения не предусмотрено: отказ защищает от холостой петли, которая без него расходует лимит до исчерпания.

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

Обычной интеграции ничего менять не нужно. Если клиент сам продолжает ход без нового сообщения пользователя, получив agent_turn_loop_detected, остановите ход и дождитесь сообщения пользователя: новое сообщение с ролью user начинает счёт заново.

NEW-0928-8: Доступны настройки Definition of Done и данные метрик спринта

API Вайбкод добавил четыре маршрута Definition of Done — чтение настроек группы, проверку, нужен ли DoD задаче, сохранение настроек типа и сохранение списка DoD задачи, — а также два маршрута для данных спринта: /v1/scrum/groups/:groupId/burn-down и /v1/scrum/groups/:groupId/team-speed. Они возвращают результат Битрикс24 в data без вычисления метрик на платформе.

NEW-0928-9: Потоки и задачи по статусам доступны через API

Появились девять маршрутов /v1/tasks/flows для создания, чтения, изменения и удаления потока, переключения его активности и получения отдельных списков выполненных, ожидающих и выполняемых задач. Маршруты вызывают соответствующие методы Bitrix24 и возвращают их результат в data. Для чтения подходит READONLY-ключ; для изменений нужен ключ с правом записи. Справка по потокам.

FIX-0928-11: Публичное приложение сообщает о недоступности при запрете пробуждения

Было

Публичное приложение без туннеля при запрете пробуждения продолжало показывать ожидание запуска со статусом 503, хотя поднять его было нельзя.

Стало

Только для режима PUBLIC подтверждённый запрет пробуждения при отсутствии туннеля даёт 409: браузеру — «Приложение временно недоступно» с кнопкой «Обновить», машинному клиенту — BH_APP_UNAVAILABLE в JSON. Ответ не раскрывает причину, баланс или бренд подписки и не содержит Retry-After. Автоматическое ожидание прекращается, пробуждение не запускается. В приватном режиме для опознанного пользователя сохраняется 402 BH_WAKE_BLOCKED.

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

Успешные запросы работают как прежде. Не повторяйте запрос с BH_APP_UNAVAILABLE автоматически. После снятия запрета приложение можно открыть вручную по прежнему адресу, POST автоматически не повторяется.

BC-0928-12: доступ к исходникам сервера привязан к ключу владельца

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

Было

Второй личный ключ того же пользователя получал 404 на GET /v1/infra/servers/:id, но мог читать и менять исходники через серверные операции с исходниками. POST /v1/infra/servers/:id/sources/cleanup отвечал 200.

Стало

Второй личный ключ без привязки приложения к серверу получает 404 и на запросы к исходникам, в том числе если его владелец — администратор. Указатели в GET /v1/me/sources и GET /v1/apps/:id/sources больше не обещают ему доступ. Текущий ключ сервера и личный ключ его привязанного приложения сохраняют доступ; администратор по-прежнему может обращаться к серверам других пользователей.

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

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

FIX-0928-13: шаблоны, активити и роботы бизнес-процессов на портале без модуля отвечают 409 BIZPROC_MODULE_NOT_ENABLED

Было

На портале, где бизнес-процессы не входят в тариф или выключены в настройках, операции шаблонов бизнес-процессов, активити и роботов отвечали 404 ENTITY_NOT_FOUND, а на англоязычном портале — 422 BITRIX_ERROR. Такой ответ выглядел как неверный идентификатор, хотя дело было в состоянии портала. В пакетных вызовах POST /v1/batch и POST /v1/{entity}/batch тот же отказ приходил элементом с внутренним кодом Битрикс24 ERROR_METHOD_NOT_FOUND либо с общими кодами CALL_FAILED и AUTO_PAGINATION_FAILED. Разделы запущенных процессов на том же портале уже отвечали 409 BIZPROC_MODULE_NOT_ENABLED.

Стало

Все операции этих трёх сущностей, которые обращаются к Битрикс24, на портале без бизнес-процессов отвечают 409 BIZPROC_MODULE_NOT_ENABLED — так же, как раздел запущенных процессов. В пакетных вызовах ответ пакета остаётся HTTP 200, а отказавший элемент несёт код BIZPROC_MODULE_NOT_ENABLED с тем же сообщением. Сообщение называет вызванный метод Битрикс24, обе возможные причины и действие: попросить администратора портала включить бизнес-процессы. Остальные ошибки этих операций не изменились.

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

Действий не требуется: отказ как был 4xx, так и остался, а прежние 404 ENTITY_NOT_FOUND и 422 BITRIX_ERROR для этого состояния документацией не обещались. Интеграция, которая в элементе пакетного вызова ловила внутренний код ERROR_METHOD_NOT_FOUND или общие коды CALL_FAILED и AUTO_PAGINATION_FAILED, увидит для этого случая собственный код BIZPROC_MODULE_NOT_ENABLED; интеграция, которая считает незнакомый код сбоем вызова, продолжит работать. Повторять запрос бесполезно, пока бизнес-процессы на портале недоступны.

FIX-0928-15: пустые POST-запросы получают предусмотренный ответ валидации

Было

POST-запросы без тела и без Content-Type к перечисленным ниже эндпоинтам отвечали HTTP 500 вместо ответа о некорректном запросе.

Стало

Такие запросы получают уже предусмотренный HTTP 400. Для POST /v1/calls/register ответ на успешный запрос остаётся HTTP 201, а для POST /v1/connect/device/authorize ответ на успешный запрос остаётся HTTP 200.

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

Изменения не требуются. Клиенты могут обрабатывать отсутствие обязательных параметров как ошибку запроса, а не как внутреннюю ошибку сервера.

Затронутые эндпоинты: POST /v1/calls/register, POST /v1/calls/:callId/show, POST /v1/calls/:callId/hide, POST /v1/calls/:callId/finish, POST /v1/calls/:callId/transcription, POST /v1/calls/auto-call, POST /v1/calls/auto-call-audio, POST /v1/calls/callback, POST /v1/connect/device/authorize.

FIX-0928-16: предупреждение о доступе приложения к порталу после деплоя

Было

Успешный ответ POST /v1/infra/servers/:id/deploy с OAuth-app-ключом не напоминал, что ключ запроса не переносится автоматически в окружение приложения, а доступ приложения к порталу не проверен.

Стало

Успешный ответ добавляет это пояснение в warnings: в JSON отдельной виртуальной машины и Galaxy-приложения, а в SSE — в событии done. Успех деплоя и прежние предупреждения сохраняются. Для личного ключа и при ошибке деплоя новое предупреждение не добавляется. Переменные окружения и ключи не меняются; предупреждение не утверждает, что у приложения отсутствуют учётные данные. Контракт приложения описывает настройку авторизации от имени пользователя и headless-сервиса.

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

Обязательных изменений в клиентах API нет. Если приложение должно обращаться к Битрикс24, его автору нужно явно настроить runtime-авторизацию; успешный deploy её не подтверждает. Обрабатывайте новый элемент warnings как рекомендацию, а не ошибку публикации.

FIX-0928-17: ключ десктопа Коворка снова читает исходники сервера своего приложения

Было

GET /v1/infra/servers/{id}/sources и GET /v1/infra/servers/{id}/sources/{versionId}/download отвечали ключу десктопа Коворка 404 SERVER_NOT_FOUND, хотя GET /v1/applications отдавал этому же ключу карточку приложения с этим сервером. GET /v1/me/sources для такой строки возвращал reachableViaApi: false и пустые указатели.

Стало

Ключ десктопа Коворка читает список версий и получает ссылку на скачивание, если на сервере есть живая карточка приложения того же пользователя на том же портале. GET /v1/me/sources отдаёт для такой строки reachableViaApi: true и рабочие указатели. Запись, удаление и очистка версий этому ключу по-прежнему закрыты; прочие вторые личные ключи владельца сервера доступа не получают.

BC-0928-18: скоуп vibe:onec требует доступа к 1С, а раздел 1С в самоописании — самого скоупа

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

Было

POST /v1/keys, PATCH /v1/keys/:id, POST /v1/apps и PATCH /v1/apps/:id выдавали скоуп vibe:onec без проверки того, есть ли у владельца ключа доступ к 1С. Ключ или приложение создавались без отказа, а вызовы раздела 1С отвечали 403 ONEC_USER_NOT_MAPPED. Каталог GET /v1/onec/tools при этом требует только скоуп — имена опубликованных методов и колонок базы 1С были доступны и без доступа к 1С. Раздел интеграции 1С в GET /v1/guide (блок onecApi) и в GET /v1/me (строка api._rules) отдавался любому ключу российского сегмента, включая ключи без vibe:onec, которым сам раздел недоступен.

Стало

Запрос скоупа vibe:onec без доступа к 1С отвечает 403 ONEC_ACCESS_REQUIRED — на всех четырёх адресах одинаково. Доступ выдаёт администратор портала: кабинет → Интеграция 1С → сопоставления и назначения. Проверяется доступ того, кому право принадлежит — владельца ключа или приложения, — а не того, кто послал запрос: администратор, правящий чужой ключ, получает ответ по доступу владельца, а не по своему. Отказ не гарантирован: часть запросов может пройти, поэтому полагаться на него как на признак отсутствия доступа нельзя. Правка (PATCH), которая оставляет уже выданный vibe:onec на месте и не добавляет новых прав, не отбивается. Раздел интеграции 1С в GET /v1/guide и GET /v1/me теперь требует сам скоуп vibe:onec — ключ без него раздел больше не видит.

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

Скрипт, который выпускает или правит ключи и приложения со скоупом vibe:onec, обрабатывает 403 ONEC_ACCESS_REQUIRED как отказ выписки: не повторяет запрос, а просит администратора портала выдать сотруднику доступ к 1С (кабинет → Интеграция 1С → сопоставления и назначения) либо выпускает ключ без vibe:onec. Агент, который читал раздел интеграции 1С в GET /v1/guide или GET /v1/me ключом без vibe:onec, получает этот раздел только ключом со скоупом. Ключам и приложениям, которые уже держат vibe:onec, менять ничего не нужно: правка и перевыпуск без добавления права не отбиваются.

NEW-0928-19: сброс лимитов Cowork/Code по праву акции

Новый метод POST /v1/cowork/limits/reset тратит право сбросить расход всех трёх окон квоты — пятичасового, недельного и месячного. Право выдаётся по акциям платформы и действует до окончания акции. Тратить его может только ключ десктопа Cowork/Code; rightId служит ключом идемпотентности, и повтор с тем же значением возвращает alreadyUsed: true.

В GET /v1/cowork/me и GET /v1/cowork/state появляется блок limitReset: права пользователя, момент последнего сброса и признак замороженного счёта. Блок приходит, когда возможность включена для аккаунта, и до первой акции список прав в нём пуст. Проверяйте наличие ключа: без него возможности нет.

FIX-0928-20: чтение сайтов на аккаунте без модуля «Сайты» отвечает отдельным кодом

Было

Чтение сайтов на аккаунте Битрикс24, где модуль «Сайты» недоступен, отвечало 422 BITRIX_ERROR с текстом Битрикс24 «Method not found!» или 404 ENTITY_NOT_FOUND при русском «Метод не найден». Эти коды не объясняли, что модуль выключен, а повтор запроса возвращал тот же отказ сколько угодно раз.

Стало

Те же запросы отвечают 409 LANDING_MODULE_NOT_ENABLED, и сообщение называет причину прямо: на аккаунте нужно включить раздел «Сайты», после чего методы landing.* станут доступны. Прочие ошибки Битрикс24 на тех же адресах свой прежний код сохраняют.

Затронутые эндпоинты: GET /v1/sites, GET /v1/sites/{id}, POST /v1/sites/search, POST /v1/sites/aggregate и прежний GET /v1/sites/aggregate. Создание, изменение и удаление сайта идут другими методами Битрикс24 и отвечают как прежде.

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

Менять вызовы не нужно. Обработчик, который разбирал текст ответа, чтобы отличить выключенный модуль от сбоя, теперь может ветвиться по коду LANDING_MODULE_NOT_ENABLED, а повтор такого запроса стоит откладывать до включения раздела — до этого ответ не изменится.

NEW-0928-21: спека называет отказ раскатки у методов Follow-up звонков

Методы Follow-up звонков выходят в обновлении Битрикс24 call 26.600.0 и приехали пока не на все порталы. На портале без обновления вызов отвечает 422 METHOD_NOT_YET_AVAILABLE, а в теле ошибки приходит поле error.release с номером ожидаемого обновления — это признак раскатки, а не ошибка интеграции. Раньше про это знали только страницы документации, а спека openapi.json обещала на 422 единственный код BITRIX_ERROR, поэтому клиент, собранный по спеке, отличить раскатку от отказа Битрикс24 не мог. Теперь оба кода названы в спеке, а описание операций несёт номер релиза. Спека портал не опрашивает, поэтому заметка общая и состоянием вашего портала не является: вызовите метод, 200 означает, что он там уже живой. Затронуты POST /v1/calls/followups/list и GET /v1/calls/followups/:callId. Менять в интеграции ничего не нужно.

NEW-0928-22: Облачные задания Коворка

Для клиентского приложения Коворк добавлены API создания однократных и повторяющихся заданий после подтверждения пользователя, чтения расписания, состояния и результата каждого запуска, изменения текста и расписания, приостановки, возобновления, остановки будущих запусков, ручного запуска через POST /v1/cowork/cloud-tasks/:id/runs, отзыва доступа и получения событий через replay/SSE. Расписание принимает часовой пояс пользователя и поддерживает календарное повторение и интервал; ручной запуск сдвигает следующий интервальный запуск, но не календарный. Уже начатый запуск при остановке задания продолжается. Запросы требуют действующий ключ Коворка и ограничены его пользователем и порталом. Создание, подтверждение, загрузка выбранных входных файлов, изменение и ручной запуск требуют ключ в режиме записи; ключ «только чтение» может просматривать задания и результаты. После подтверждения задания Коворк может передать неизменяемый снимок выбранных файлов через POST /v1/cowork/cloud-task-inputs; ответная ссылка input_ref используется только для того же задания. Облачное исполнение поддерживает ограниченные операции чтения Битрикс24 и генерацию изображений с проверкой действующего доступа и обычными пользовательскими лимитами.

FIX-0928-23: Чтение исходников приложений из Коворка

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

BC-0928-24: Последовательный опрос событий бота использует сохранённую позицию

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

Было

GET /v1/bots/:botId/events без offset мог повторно выдать событие. Ответ сообщал persisted: true до завершения сохранения.

Стало

Успешный ответ с persisted: true подтверждает сохранённую позицию для следующего опроса. Пересекающийся опрос получает 409 BOT_EVENTS_BUSY; невозможность подтвердить результат — 503 BOT_EVENTS_UNAVAILABLE без событий. Оба ответа содержат Retry-After: 1. Сбой подсистемы опроса может затронуть несколько ботов одновременно. Документация limit уточнена: действующий диапазон 1-200, значения вне него ограничиваются границами без новой ошибки. Явный offset ниже сохранённого по-прежнему не продвигает позицию.

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

Дождитесь завершения одного опроса перед следующим. На 409 BOT_EVENTS_BUSY и 503 BOT_EVENTS_UNAVAILABLE повторите запрос через секунду согласно Retry-After. Для продолжения используйте запрос без offset либо nextOffset предыдущего ответа. Сохраняйте защиту от повторной обработки: при обрыве соединения после сохранения позиции однократная обработка приложением не гарантируется.

NEW-0928-25: демо-статус места в ответах подписки Коворк/Код

Ответы GET /v1/cowork/me и GET /v1/cowork/state содержат поле demo. Пока у места идёт демо-доступ, это объект с моментом окончания until и ссылкой на правила использования rulesUrl, иначе null. Тариф места при этом остаётся FREE, а доли квоты уже считаются от лимитов демо — показывайте тариф как «Demo» с датой окончания и ссылкой на правила.

FIX-0928-26: ответ чата без вызовов инструментов больше не помечен как вызов инструментов

Было

POST /v1/chat/completions мог вернуть ответ с finish_reason: "tool_calls", в котором не было ни одного вызова инструмента: модель попыталась вызвать инструмент, но вызов остался обычным текстом. Так было и в потоке, и в ответе без потока. Агентный клиент по такой причине завершения ждал результатов инструментов, не завершал ход и повторял запрос с тем же контекстом, пока не упирался в лимит шагов.

Стало

Если в ответе нет ни одного вызова инструмента, finish_reason: "tool_calls" приходит как finish_reason: "stop": в потоке — в завершающем событии, без потока — в choices[].finish_reason. Ответы с настоящими вызовами инструментов не меняются. Статус ответа по-прежнему 200.

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

Менять ничего не нужно. Клиент завершает ход по finish_reason: "stop" и показывает полученный текст вместо повторного запроса.

FIX-0928-27: сбой связи с порталом в операциях бизнес-процессов больше не выдаётся за выключенный модуль

Было

Операции раздела «Бизнес-процессы» — GET /v1/workflows, запуск, остановка, запись в журнал и отправка события — отвечали 409 BIZPROC_MODULE_NOT_ENABLED, если в тексте ошибки встречались слова «Method not found», независимо от кода ответа. Под это попадали временные сбои: портал вернул HTML-страницу вместо JSON и в её тексте были эти слова (502), либо лимит запросов ответил 429 с такими же словами в тексте. Клиент получал постоянный отказ «попросите администратора включить модуль» и переставал повторять запрос, хотя повтор помог бы.

Стало

409 BIZPROC_MODULE_NOT_ENABLED выдаётся только на клиентский отказ портала класса 4xx (кроме 429) — так же, как в сущностях /v1/bizproc-* и в batch. Временный сбой отвечает своим кодом: 502 BITRIX_UNAVAILABLE или 429 RATE_LIMITED, и такой запрос можно повторить. Портал без модуля бизнес-процессов по-прежнему получает 409 BIZPROC_MODULE_NOT_ENABLED с тем же сообщением.

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

Действий не требуется. Интеграция, которая повторяет запросы на 502 и 429, теперь повторит и эти случаи, а не остановится на 409.