# Изменения API: 12 октября 2026 [← Журнал изменений](/docs/changelog) · [Октябрь 2026](/docs/changelog/2026-10) ### FIX-1012-1: Понятная причина недоступности сервиса управления сервером **Было** При транспортном сбое сервиса управления сервером [POST /v1/infra/servers/{id}/reboot](/docs/infra/lifecycle/reboot) для хоста галактики возвращал категорию `GENERIC`, а [GET /v1/infra/servers/{id}/repair-status](/docs/infra/lifecycle/repair-status) мог содержать только `fetch failed` в `data.error`. **Стало** Ответ перезагрузки хоста галактики содержит `TRANSPORT_UNAVAILABLE` в `error.category`, если транспортный сбой не сопровождается более точной причиной ошибки. Статус починки содержит понятную английскую подсказку в `data.error`: сервис управления сервером недоступен, повторите попытку через несколько минут. В том же тексте указан шестисимвольный код обращения. **Влияние на интеграторов** Коды HTTP и форма ответа не изменились. При обработке `error.category` учитывайте новую категорию `TRANSPORT_UNAVAILABLE`. Текст `data.error` предназначен для показа пользователю. ### NEW-1012-2: Пакетное чтение каталогов и хранилищ доступно в OpenAPI Работающие методы `POST /v1/catalogs/batch` и `POST /v1/storages/batch` теперь описаны в OpenAPI и справочнике API, чтобы агент мог их обнаружить. Пакет каталогов отвечает данными для `list` и `get`; принятое действие `fields` возвращает пустой объект, поскольку у каталогов нет метода схемы полей в Битрикс24. Пакет хранилищ отвечает данными для `list`, `get` и `fields`. Вызов выбирает одно действие и передаёт непустой массив `calls` (по умолчанию до 50 вызовов). Вызовы выполняются последовательно; результат каждого содержит данные или ошибку. Ответ остаётся HTTP 200 при ошибке отдельного вызова. ### NEW-1012-3: Коннекторы компании для ключа приложения Ключ приложения Вайбкод со скоупом `vibe:connectors` может вызывать инструменты общих подключений портала. [GET /v1/connectors](/docs/connectors-host) отдаёт каталог коннекторов, [POST /v1/connectors/mcp](/docs/connectors-mcp) вызывает инструменты, `GET /v1/connectors/write-tickets/{id}` отдаёт исход подтверждения записи, а [GET /v1/me](/docs/keys-auth/me) у допущенного ключа отдаёт блок `data.connectorHost`. Скоуп выдаётся только явно и в набор по умолчанию не входит. Приложению доступны только подключения компании, права берутся от владельца ключа. Запись владелец подтверждает в веб-кабинете, платные вызовы оплачиваются с баланса портала. Пока функция не включена для портала, маршруты отвечают `404 ROUTE_NOT_FOUND`. При включённой функции запрещённый ключ, маршрут или операция получают `403 CONNECTOR_KEY_NOT_ALLOWED`. ### BC-1012-4: Право vibe:storage не выдаётся приложениям Partner Connect > Поддержка старого формата до: не предусмотрена **Было** Приложение [Partner Connect](/docs/partner-connect) могло получить `vibe:storage` так же, как `vibe:search`, `vibe:infra` и `vibe:feedback`: право выдавал платформенный администратор проверенному приложению, после чего оно приходило на ключ через согласие пользователя. **Стало** `vibe:storage` приложению Connect не выдаётся. Ключ, выданный через Connect, попадает в ту же область [хранилища](/docs/storage), что и личные ключи подключившего пользователя, и с этим правом приложение видело бы все файлы, загруженные его личными ключами. Запрос права при регистрации приложения по-прежнему отклоняется кодом `SCOPE_NOT_ALLOWED`, а платформенный администратор это право приложению Connect больше не выдаёт. Изменение уже действует. Приложений Connect с этим правом не было, поэтому срок поддержки прежнего порядка не предусмотрен. **Что делать интеграторам** Не закладывайте хранение файлов на ключ Connect и не запрашивайте `vibe:storage` в заявке на верификацию. Права Битрикс24, `vibe:ai` и права, которые выдаёт платформенный администратор, работают как раньше. ### FIX-1012-5: Отказ по скоупу vibe:storage у ключа Partner Connect больше не советует выдачу администратором **Было** Когда ключу, выданному через [Partner Connect](/docs/partner-connect), не хватало `vibe:storage`, отказ `403` с причиной `key_scope_missing` советовал в `error.hint`: если платформенный администратор ещё не выдал право приложению, сначала его выдаёт он, затем приложение запрашивает право и заново проводит пользователя через согласие. `error.userMessage` говорил то же: разработчик должен запросить право и заново получить согласие пользователя. **Стало** Для этого случая `error.fix` = `{ "action": "none", "via": "platform" }`. `error.hint` говорит, что `vibe:storage` приложениям Partner Connect не выдаётся — ни повторным согласием, ни платформенным администратором. `error.userMessage` говорит, что этому ключу право не добавить. Код, статус и `message` отказа прежние, остальные скоупы ключа Partner Connect отвечают как раньше. Подробности — [Авторизация, ключи и права](/docs/errors/auth). **Влияние на интеграторов** Действий не требуется. Если ваш код запускал повторное согласие по этому отказу, для `vibe:storage` он больше его не получит: право ключу Connect не выдаётся. ### NEW-1012-6: отказы для клиентов с режимом COMPANY Для клиентов Partner Connect с режимом `COMPANY` выдача пока закрыта: `/v1/connect/authorize` возвращает на зарегистрированный адрес ошибку `access_denied` с `CONNECT_COMPANY_DISABLED` или `CONNECT_COMPANY_NOT_READY`, без кода авторизации. Обмен authorization-кода на `/v1/connect/token` возвращает HTTP 403 с тем же кодом. Запуск и обмен device-кода отклоняются с HTTP 400 и `CONNECT_COMPANY_DEVICE_FLOW_FORBIDDEN`. Обычный режим `PERSONAL` продолжает работать. ### NEW-1012-7: Коды отказа для подключений компании В [Partner Connect](/docs/partner-connect) описаны коды HTTP 403 для подключений COMPANY: `CONNECT_COMPANY_STORAGE_NOT_READY` для хранилища и `CONNECT_COMPANY_DERIVED_TOKEN_FORBIDDEN` для производных токенов и ключей. OpenAPI публикует код и HTTP-статус отказа отдельно для COMPANY. Выдача подключений COMPANY остаётся закрытой с кодом `CONNECT_COMPANY_NOT_READY`. ### FIX-1012-8: Единый отказ закрытой выдачи подключения компании **Было** Закрытая выдача Partner Connect в режиме `COMPANY` возвращала `CONNECT_COMPANY_DISABLED` либо `CONNECT_COMPANY_NOT_READY`. **Стало** `GET /v1/connect/authorize` и `POST /v1/connect/token` при закрытой выдаче в режиме `COMPANY` возвращают единый код `CONNECT_COMPANY_NOT_READY`. Выдача остаётся недоступной. ### FIX-1012-9: занятый путь загрузки приложения допускает повтор деплоя **Было** Если путь исходников занимала другая загрузка, `POST /v1/infra/servers/:id/deploy` отвечал `502 GALAXY_APP_BUILD_FAILED` и переводил приложение в `error`. **Стало** Ответ — `409 GALAXY_UPLOAD_BUSY`, `error.retryable: true`, `error.retryAfter: 10`, `error.hint` и заголовок `Retry-After: 10`. Статус приложения сохраняется. Подождите не менее 10 секунд и повторите тот же запрос для того же приложения. Если сборка запущена в фоне через `POST /v1/infra/servers` с `source`, новое приложение сначала остаётся в `provisioning`, а `GET /v1/infra/servers/:id` показывает `buildHint` с советом повторить деплой. Зависшая попытка после 20 минут и следующей проверки в пределах 5 минут переводится в `error` с сохранением причины занятого пути и подсказки. Повторите тот же деплой и в этом состоянии: новая попытка возвращает слот в `provisioning`, данные `/data` сохраняются. Фоновая сборка исходников после создания сервера автоматически не повторяется. Hermes повторяет свою загрузку не раньше чем через 3 минуты; прежний лимит ожидания 30 минут завершает попытку с сохранением причины занятого пути и подсказки. Лента активности показывает причину занятого пути. Удалять приложение или снимать блокировки не нужно. ### NEW-1012-10: Опрос статуса подключения Компании [GET /v1/connect/company/status](/docs/partner-connect#опрос-подключения-компании) возвращает состояние собственного подключения по секрету `COMPANY`, версии состояния и секрета, доступные возможности и следующее действие. Ответ не содержит персональных данных, секретов и URL и запрещает кэширование. Диагностика доступна для `STATUS_ONLY`. При ограничении частоты опроса ответ содержит `Retry-After`. Битрикс24, ИИ и файлы пока закрыты. ### NEW-1012-11: Признак размещения приложения в ответах о приложениях [GET /v1/apps](/docs/apps/list), [GET /v1/apps/{id}](/docs/apps/get) и остальные ответы с объектом приложения, например [POST /v1/apps](/docs/apps/create) и [POST /v1/apps/{id}/relink-oauth](/docs/apps/relink-oauth), возвращают три новых поля. `hosting` показывает, где работает приложение: `platform` — на сервере платформы, привязанном к приложению или принадлежащем этому аккаунту Битрикс24, или на подтверждённом своём домене такого сервера, либо адреса у приложения нет вовсе, `platform-orphan` — адрес на поддомене платформы без работающего сервера, `external` — любой другой адрес, в том числе сервер платформы другого аккаунта Битрикс24. `externalHost` — имя хоста для `external`, иначе `null`; у `external` тоже бывает `null`, если в адресе нет хоста. `externalRegistrable` — регистрируемый домен этого хоста, иначе `null`. Поле `appUrl` не меняется. ### BC-1012-12: datetime-фильтры сохраняют явно заданный часовой пояс > Поддержка старого формата до: не предусмотрена **Было** Фильтры дат в API Вайбкод удаляли `Z` или числовое смещение без пересчёта часов. Значение `updatedAt` из ответа, переданное в `$gte`, могло задавать другой момент; пакетные окна также теряли зону и дробные секунды. **Стало** Явно заданные `Z`/offset и дробные секунды передаются в Битрикс24 целиком, в том числе в пакетных окнах. `2026-10-05T19:20:22.000Z` и `2026-10-05T22:20:22.000+03:00` задают один момент. Наивные строки и `YYYY-MM-DD` сохраняют локальную семантику Битрикс24 и в автоматических окнах: раньше окна по умолчанию отправляли их как момент UTC, и на портале с поясом UTC+3 первые часы диапазона выпадали. `X-Vibe-Timezone` действует только на запись. Если одна граница локальная, а другая с зоной, фильтр исполняется без автоматического разбиения на окна. При включённом автоматическом разбиении поиск возвращает `DATE_WINDOWING_SKIPPED` в `meta.warnings`: выборка на методах Битрикс24 с фильтрацией после пагинации может быть неполной. Для разбиения задайте явную зону на обеих границах. **Что делать интеграторам** Передавайте значение из ответа без поправки часов; уберите ручную компенсацию прежнего среза зоны, если она была в интеграции. ### BC-1012-13: Удаление приложения требует подтверждения остановки контейнера > Поддержка старого формата до: не предусмотрена **Было** `DELETE /v1/infra/servers/:id` для приложения на хосте с ошибкой `GUEST_NOT_BOOTING` мог успешно удалить только запись и привязку, оставив контейнер на недоступном хосте. **Стало** если остановка и удаление контейнера не подтверждены, запрос возвращает `502`; запись и привязка сохраняются для повторной попытки. Подтверждённое удаление хоста также позволяет завершить очистку его приложений. Прежнее поведение отключено без переходного периода: оно позволяло работающему контейнеру пережить удаление приложения. **Что делать интеграторам** обрабатывайте `502` как незавершённое удаление. Сохраните идентификатор приложения, восстановите доступность хоста и повторите DELETE либо обратитесь в поддержку для подтверждённого удаления хоста. Не считайте ресурс удалённым до успешного ответа. ### NEW-1012-14: Повторяемый отказ при занятой привязке сервера `DELETE /v1/infra/servers/:id` может вернуть `409 REISSUE_IN_PROGRESS`, пока ключ приложения или его привязка к серверу заняты, например перевыпуском ключа или доставкой секретов. Этот запрос ничего не удалил; повторите его чуть позже. Такой же код при `POST /v1/infra/servers` означает, что новая машина не создана и запрос можно повторить после завершения параллельной операции. ### NEW-1012-15: Ключи управления доступны в OpenAPI OpenAPI и справочник API Вайбкод теперь описывают семь работающих методов [ключей управления](/docs/management-keys): [GET /v1/keys](/docs/management-keys), [POST /v1/keys](/docs/management-keys), [GET /v1/keys/{id}](/docs/management-keys), [PATCH /v1/keys/{id}](/docs/management-keys), [DELETE /v1/keys/{id}](/docs/management-keys), [POST /v1/keys/{id}/rotate](/docs/management-keys) и [GET /v1/portals](/docs/management-keys). Агенты и генераторы клиентов видят параметры, ответы, отказы и права вызывающего ключа. Методы доступны в срезах `vibe:mgmt:keys` и `vibe:mgmt:portals`. Секрет возвращается однократно при создании или ротации, чтение и список содержат только безопасные сведения. Таймаут выпуска ключа теперь отвечает 503 вместо 504, как остальные таймауты платформы, и повторять запрос сразу по-прежнему не нужно. Чтобы добавить методы в генерируемый клиент, обновите его из актуальной спецификации. ### NEW-1012-16: Вызовы по расписанию Появились задачи сервера для вызова HTTP-обработчика приложения по расписанию: [GET /v1/infra/servers/:id/jobs](/docs/infra/jobs/list) — список, [POST /v1/infra/servers/:id/jobs](/docs/infra/jobs/create) — создание, [PATCH /v1/infra/servers/:id/jobs/:jobId](/docs/infra/jobs/update) — замена настроек, [DELETE /v1/infra/servers/:id/jobs/:jobId](/docs/infra/jobs/delete) — удаление, [POST /v1/infra/servers/:id/jobs/:jobId/run](/docs/infra/jobs/run) — ручной запуск, [GET /v1/infra/servers/:id/jobs/:jobId/runs](/docs/infra/jobs/runs) — журнал запусков и [POST /v1/infra/servers/:id/jobs/:jobId/rotate-secret](/docs/infra/jobs/rotate-secret) — замена секрета. Вызов обработчика подписан; повторные попытки одного запуска сохраняют один `runId`, а результат и попытки видны в журнале. Настройка доступна также через инструмент MCP `manage_server_jobs`. [Документация](/docs/infra/jobs). ### NEW-1012-17: Очистка истории чата для себя или всех [POST /v1/chats/:dialogId/history/clear](/docs/chats/management/history-clear) принимает обязательное поле `scope`: `self` очищает историю для вызывающего пользователя, `all` — для всех участников. Чат сохраняется. Требуются скоуп `im` и режим доступа с разрешением на запись. Право выполнить операцию проверяет Битрикс24. Очистка истории возвращает `data.result: true` только после явного подтверждения. Отсутствие подтверждения даёт `502 BITRIX_UNAVAILABLE`. ### FIX-1012-18: Подтверждение удаления чата **Было** [DELETE /v1/chats/:dialogId](/docs/chats/management/delete) мог сообщить об успехе без явного подтверждения удаления со стороны Битрикс24. **Стало** Ответ на подтверждённое удаление по-прежнему имеет статус `200` и содержит `data.result: true`. Если подтверждение отсутствует, ответ содержит `502 BITRIX_UNAVAILABLE`. Запрос не повторяется автоматически после ответа 503 от Битрикс24. **Влияние на интеграторов** Проверяйте состояние чата перед ручным повтором после 502: операция могла уже изменить данные. Успешный ответ на подтверждённое удаление не изменился. ### FIX-1012-19: файлы приложения доступны после перевыпуска ключа и передачи приложения **Было** Ключ приложения видел в хранилище только файлы, которые записал владелец этого ключа. После перевыпуска ключа авторизации приложения или передачи приложения другому сотруднику новый ключ отвечал `404 STORAGE_OBJECT_NOT_FOUND` на ранее загруженные файлы, а [список объектов](/docs/storage/objects/list) их не показывал. Повторная загрузка по тому же ключу отвечала `409 STORAGE_KEY_OWNED_ELSEWHERE`. **Стало** Файлы принадлежат приложению. Ключ приложения читает, перечисляет и перезаписывает все файлы своего приложения, кто бы их ни загрузил, в том числе после перевыпуска ключа и передачи приложения. [GET /v1/storage/objects/{key}](/docs/storage/objects/get) для таких файлов снова отвечает перенаправлением на файл. Файлы сотрудника внутри приложения по-прежнему доступны только с токеном этого сотрудника. Личные ключи разработчика работают как раньше. **Влияние на интеграторов** Менять ничего не нужно. После передачи приложения прежние файлы видны сразу, в том числе для передач, сделанных раньше. Сохранение файлов при перевыпуске действует для ключей, перевыпущенных после этого исправления.