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

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

### 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. [Справка по результатам задач](/docs/entities/tasks/results-v3).

### 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](/docs/ai/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-ключ; для изменений нужен ключ с правом записи. [Справка по потокам](/docs/entities/tasks/flows).

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

**Было**

[Публичное приложение](/docs/infra/app-runtime) без туннеля при запрете пробуждения продолжало показывать ожидание запуска со статусом `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](/docs/infra/servers/get), но мог читать и менять исходники через [серверные операции с исходниками](/docs/source-storage/servers). [POST /v1/infra/servers/:id/sources/cleanup](/docs/source-storage/retention) отвечал `200`.

**Стало**

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

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

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

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

**Было**

На портале, где бизнес-процессы не входят в тариф или выключены в настройках, операции [шаблонов бизнес-процессов](/docs/entities/bizproc-templates/list), [активити](/docs/entities/bizproc-activities/list) и [роботов](/docs/entities/bizproc-robots/list) отвечали `404 ENTITY_NOT_FOUND`, а на англоязычном портале — `422 BITRIX_ERROR`. Такой ответ выглядел как неверный идентификатор, хотя дело было в состоянии портала. В пакетных вызовах [POST /v1/batch](/docs/batch) и `POST /v1/{entity}/batch` тот же отказ приходил элементом с внутренним кодом Битрикс24 `ERROR_METHOD_NOT_FOUND` либо с общими кодами `CALL_FAILED` и `AUTO_PAGINATION_FAILED`. Разделы [запущенных процессов](/docs/automation/workflows/list) на том же портале уже отвечали `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](/docs/telephony/crm/register) ответ на успешный запрос остаётся HTTP 201, а для [POST /v1/connect/device/authorize](/docs/partner-connect) ответ на успешный запрос остаётся HTTP 200.

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

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

**Затронутые эндпоинты:** [POST /v1/calls/register](/docs/telephony/crm/register), [POST /v1/calls/:callId/show](/docs/telephony/crm/show), [POST /v1/calls/:callId/hide](/docs/telephony/crm/hide), [POST /v1/calls/:callId/finish](/docs/telephony/crm/finish), [POST /v1/calls/:callId/transcription](/docs/telephony/crm/transcription), [POST /v1/calls/auto-call](/docs/telephony/outbound/auto-call), [POST /v1/calls/auto-call-audio](/docs/telephony/outbound/auto-call-audio), [POST /v1/calls/callback](/docs/telephony/outbound/callback), [POST /v1/connect/device/authorize](/docs/partner-connect).

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

**Было**

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

**Стало**

Успешный ответ добавляет это пояснение в `warnings`: в JSON отдельной виртуальной машины и Galaxy-приложения, а в SSE — в событии `done`. Успех деплоя и прежние предупреждения сохраняются. Для личного ключа и при ошибке деплоя новое предупреждение не добавляется. Переменные окружения и ключи не меняются; предупреждение не утверждает, что у приложения отсутствуют учётные данные. [Контракт приложения](/docs/infra/app-runtime) описывает настройку авторизации от имени пользователя и 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](/docs/apps/create) и [PATCH /v1/apps/:id](/docs/apps/update) выдавали скоуп `vibe:onec` без проверки того, есть ли у владельца ключа доступ к 1С. Ключ или приложение создавались без отказа, а вызовы раздела 1С отвечали 403 `ONEC_USER_NOT_MAPPED`. Каталог `GET /v1/onec/tools` при этом требует только скоуп — имена опубликованных методов и колонок базы 1С были доступны и без доступа к 1С. Раздел интеграции 1С в [GET /v1/guide](/docs/keys-auth/guide) (блок `onecApi`) и в [GET /v1/me](/docs/keys-auth/me) (строка `api._rules`) отдавался любому ключу российского сегмента, включая ключи без `vibe:onec`, которым сам раздел недоступен.

**Стало**

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

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

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

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

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

В [GET /v1/cowork/me](/docs/cowork/me) и [GET /v1/cowork/state](/docs/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](/docs/entities/sites/list), [GET /v1/sites/{id}](/docs/entities/sites/get), [POST /v1/sites/search](/docs/entities/sites/search), [POST /v1/sites/aggregate](/docs/entities/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](/docs/calls/followup/list) и [GET /v1/calls/followups/:callId](/docs/calls/followup/get). Менять в интеграции ничего не нужно.

### 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](/docs/bots/events/polling) без `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](/docs/cowork/me) и [GET /v1/cowork/state](/docs/cowork/state) содержат поле `demo`. Пока у места идёт демо-доступ, это объект с моментом окончания `until` и ссылкой на правила использования `rulesUrl`, иначе `null`. Тариф места при этом остаётся `FREE`, а доли квоты уже считаются от лимитов демо — показывайте тариф как «Demo» с датой окончания и ссылкой на правила.

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

**Было**

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

**Стало**

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

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

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

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

**Было**

Операции раздела «Бизнес-процессы» — [GET /v1/workflows](/docs/automation/workflows/list), запуск, остановка, запись в журнал и отправка события — отвечали `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`.