# Изменения API: 16 октября 2026 [← Журнал изменений](/docs/changelog) · [Октябрь 2026](/docs/changelog/2026-10) ### BC-1016-1: Доступ к файлам после передачи приложения > Поддержка старого формата до: не предусмотрена **Было** Прежний владелец приложения мог читать записанные им файлы через личный ключ разработчика после передачи приложения. **Стало** Файлы приложения доступны через личный ключ только текущему держателю приложения. Прежний владелец получает 404 и больше не видит эти файлы в списке. Для файлов сотрудников сохраняется дополнительное ограничение по владельцу файла. Личные файлы разработчика остаются доступны. **Что делать интеграторам** После передачи приложения обращайтесь к файлам с личным ключом текущего держателя или ключом самого приложения. Возврат прежнего доступа не предусмотрен из-за исправления проверки прав. ### FIX-1016-2: открытие из каталога предлагает авторизацию и серверу на личном ключе **Было** Экран «Авторизовать приложение» при открытии из каталога Битрикс24 появлялся, только если сервер работал на ключе приложения. Сервер на личном ключе запускался без сессии, хотя платформа находила его приложение по адресу сервера: шлюз не проставлял `X-Vibe-Authorization`, и вызовы к API отвечали `401`. Тот же сотрудник открывал приложение из встройки в меню без ошибок. **Стало** Если у сервера на личном ключе ровно одно приложение владельца ключа с адресом этого сервера и у приложения есть зарегистрированное OAuth-приложение, пользователь без доступа видит тот же экран с кнопкой «Авторизовать приложение», что и на ключе приложения. После авторизации приложение открывается с сессией. Если таких приложений несколько или авторизовать нечем, запуск идёт как раньше, без сессии. **Влияние на интеграторов** Менять код не нужно. Приложение на личном ключе, которому сессия не нужна, теперь при первом открытии из каталога один раз попросит пользователя авторизовать его. ### FIX-1016-3: цены серверов учитывают актуальный прайс-лист **Было** Каталоги и карточки серверов могли показывать стандартную цену тарифа без индивидуальных условий плательщика. **Стало** Цены каталога и карточек теперь берутся из актуального прайс-листа платформы с учётом индивидуальных условий. Карточка существующего сервера показывает цену его владельца. Если тарифа нет в прайс-листе, используется запасная цена. **Влияние на интеграторов** Менять запросы не требуется. Поля ответа и единица `currency` сохраняются. ### FIX-1016-4: Метаданные полей создания пользователей и сайтов исправлены **Было** [GET /v1/users/fields](/docs/entities/users/fields) не отмечал `email` как обязательное поле создания. [GET /v1/sites/fields](/docs/entities/sites/fields) не отмечал `title` и `code`. Эти требования также отсутствовали в схеме запросов OpenAPI. **Стало** В ответах `/fields` эти поля имеют `required: true`. Схемы [POST /v1/users](/docs/entities/users/create) и [POST /v1/sites](/docs/entities/sites/create) требуют их присутствия. Для сайта значение `code` в схеме создания может быть пустой строкой или `null`. Схемы PATCH остаются частичными. **Влияние на интеграторов** Работающие запросы менять не нужно. Генераторы клиентов и форм теперь видят требования создания в машинном описании. ### FIX-1016-5: При замене ключа авторизации его права следуют владельцу приложения **Было** Ключ авторизации мог принадлежать другому пользователю, хотя у приложения оставался прежний владелец. Запросы с ключом учитывались от имени этого пользователя; права и жизненный цикл ключа зависели от его аккаунта. **Стало** Ключ авторизации, выпущенный взамен прежнего, принадлежит активному владельцу приложения. Запросы с ним учитывают права этого владельца, включая доступ к 1С. Жизненный цикл нового ключа привязан к владельцу приложения. После замены ключа прежний секрет больше не подходит для новых запросов. Ранее выданные ключи автоматически не мигрируются. ### BC-1016-6: Публичное хранилище отклоняет исполняемые MIME-типы с параметрами > Поддержка старого формата до: не предусмотрена **Было** Запрос `/v1/storage/objects/multipart/create` мог принять публичный объект с `Content-Type: text/html; charset=utf-8` и вернуть успешный ответ. Такой объект мог стать доступен по публичной ссылке. **Стало** Публичная загрузка с исполняемым MIME-типом отклоняется с HTTP 415 и при наличии параметров MIME. Чтение ранее сохранённого опасного публичного объекта возвращает HTTP 404. Приватные объекты и безопасные MIME-типы продолжают работать. **Что делать интеграторам** Для публичных объектов используйте безопасный MIME-тип. Если нужен исполняемый тип, храните объект приватно. ### FIX-1016-7: скачивание документа CRM больше не отдаёт текст ответа Битрикс24 вместо файла **Было** Если Битрикс24 по ссылке документа отвечал JSON вместо файла, `GET /v1/crm-documents/{id}/download`, `GET /v1/crm-documents/{id}/pdf` и `GET /v1/crm-documents/{id}/image` передавали этот JSON клиенту как содержимое документа. **Стало** Ответ JSON без ошибки возвращается как `502 DOWNLOAD_FAILED`. Если PDF или изображение документа ещё не сформированы, ответ — `409 DOCUMENT_NOT_READY`, как и при пустой ссылке на представление. **Влияние на интеграторов** Сохранённый файл больше не может оказаться текстом ответа. На `409 DOCUMENT_NOT_READY` повторите запрос позже. ### NEW-1016-8: Применение секретов приложения без деплоя Когда владелец приложения или администратор портала сохраняет значение секрета в карточке приложения, а также после [DELETE /v1/applications/:id/secrets/:name](/docs/applications/app-secrets) платформа в фоне перезапускает работающее приложение с новым набором секретов. Деплой для этого не нужен. На отдельной машине перезапускается служба приложения, в галактике контейнер пересоздаётся из текущего образа. Пока приложение перезапускается, оно не отвечает. Заведение имени без значения ничего не перезапускает. Спящая машина от изменения не просыпается: текущий набор применяется после пробуждения. Поле `state` в ответе [GET /v1/applications/:id/secrets](/docs/applications/app-secrets) показывает ход применения. Поле `status` равно `PENDING`, пока набор ждёт применения, в том числе пока машина спит, `APPLYING` во время попытки, `APPLIED` после подтверждённого применения и `FAILED`, если применить не удалось. Причина неудачи приходит в `failureCode`, а `appliedRevision` становится равным `desiredRevision`, когда набор применён. Неудачную попытку платформа повторяет сама не чаще раза в минуту, пока машина работает, а повторить сразу можно в карточке приложения. Значения `failureCode` и что делать в каждом случае — в [руководстве по секретам приложения](/docs/applications/app-secrets). ### FIX-1016-9: переподписка бота больше не отвечает 500 после таймаута Битрикс24 **Было** Если один вызов [POST /v1/bots/{botId}/resubscribe](/docs/bots/management/resubscribe) не дождался ответа Битрикс24, все следующие вызовы переподписки этого бота отвечали `500 INTERNAL_ERROR` — повтор не помогал. **Стало** Таймаут одного вызова больше не блокирует следующие: повторная переподписка проходит как обычно. Если изменить бота сейчас нельзя, метод отвечает `409`, и код ошибки говорит, поможет ли повтор: - `BOT_EFFECT_IN_PROGRESS` — над ботом выполняется другое изменение, повторите через время из заголовка `Retry-After`; - `BOT_RECOVERY_IN_PROGRESS` — идёт автоматическое восстановление бота, повторите через время из `Retry-After`; - `BOT_UNAVAILABLE` — состояние бота требует разбора, заголовка `Retry-After` нет, повтор не поможет, обратитесь в поддержку. **Влияние на интеграторов** Ничего менять не нужно. Клиент, который обрабатывает `409`, повторяет вызов только при наличии `Retry-After`. ### FIX-1016-10: Деплой на новый сервер дожидается начальной настройки **Было** [POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy) с указанным `runtime` мог завершиться ошибкой блокировки пакетов на новом отдельном сервере; повтор через несколько минут тоже мог упасть. **Стало** Перед установкой runtime деплой ожидает завершения начальной настройки до 15 минут. Ожидание отражается в `runtime:running` и `elapsedSeconds`, установка системных пакетов не прерывается. Если подготовка не завершилась или её состояние проверить не удалось, деплой возвращает явную ошибку до остановки приложения. JSON и SSE сохраняют прежний формат ответов. ### FIX-1016-11: несуществующее дело to-do отвечает 404, а не 422 **Было** [PATCH /v1/activity-todos/{id}](/docs/entities/activities/todos/update) с идентификатором, которого в Битрикс24 нет, [POST /v1/activity-todos](/docs/entities/activities/todos/create) с несуществующим `parentActivityId` и та же проверка перед [POST /v1/activities/{id}/complete](/docs/entities/activities/complete), [POST /v1/activities/{id}/postpone](/docs/entities/activities/postpone) и [POST /v1/activities/{id}/deadline](/docs/entities/activities/deadline) отвечали `422` с кодом `BITRIX_ERROR` и текстом `Bitrix24 API error: 400`. Запись не выполнялась. Справка создания и изменения to-do описывала этот ответ как `422`. **Стало** Тот же отсутствующий идентификатор отвечает `404` с кодом `ENTITY_NOT_FOUND`: для самого дела сообщение `Activity does not exist`, для родителя — `Parent activity does not exist`. Отказ, в котором портал прислал код (запрет доступа, лимит запросов, ошибка валидации), остаётся прежним. Ответ по-прежнему HTTP 201 для успешного создания и ответ по-прежнему HTTP 200 для успешного изменения и действия. ### NEW-1016-12: агентская модель bitrix/bitrixgpt-6.0-agent [GET /v1/models](/docs/ai/models/list) отдаёт новую агентскую модель `bitrix/bitrixgpt-6.0-agent` (BitrixGPT 6.0 Agent 1M) с контекстом 1 048 576 токенов. Её можно передавать в поле `model` запроса к [POST /v1/chat/completions](/docs/ai/chat/completions): модель поддерживает потоковую выдачу, вызов инструментов (`tools`) и управление рассуждением, ступени которого перечислены в поле `reasoning` её записи в выдаче. Модель добавлена в каталог и ничего не заменяет: прежние вызовы работают без изменений. ### NEW-1016-13: Ручная остановка приложения Black Hole Для обычных машинных запросов к приложению [ANY https://app-./**](/docs/infra/app-runtime), дошедших до проверки доступности, если приложение остановлено вручную, соединения с ним нет, а пробуждение не запрещено, шлюз возвращает `409 BH_APP_STOPPED` без заголовка `Retry-After` и поля `retryAfter`. Запрос не передаётся приложению. Автоматического пробуждения и повтора такого отказа нет. Запрет пробуждения имеет приоритет: в `PUBLIC` остаётся нейтральный `409 BH_APP_UNAVAILABLE`, опознанный пользователь приватного приложения получает `402 BH_WAKE_BLOCKED` с указанием, как восстановить доступ, а неопознанный — обычный ответ входа без раскрытия причины запрета. При действующем соединении сохраняются обычные проверки доступа и передача запроса приложению. Свои правила сохраняют отдельные ответы шлюза: служебные `/_gw/*`, `/tunnel`, `/tunnel/session-v1`, `/robots.txt`, карточки предпросмотра ссылок на любом пути, отказ из обратного вызова входа и перенаправления, убирающие из URL `__gw_token` или недействительный, просроченный либо уже использованный `__init`. Успешный обмен `__init` проходит проверку доступности приложения. Сон по простою по-прежнему допускает автоматическое пробуждение.