Изменения API: 12 октября 2026

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

FIX-1012-1: Понятная причина недоступности сервиса управления сервером

Было

При транспортном сбое сервиса управления сервером POST /v1/infra/servers/{id}/reboot для хоста галактики возвращал категорию GENERIC, а GET /v1/infra/servers/{id}/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 отдаёт каталог коннекторов, POST /v1/connectors/mcp вызывает инструменты, GET /v1/connectors/write-tickets/{id} отдаёт исход подтверждения записи, а GET /v1/me у допущенного ключа отдаёт блок data.connectorHost. Скоуп выдаётся только явно и в набор по умолчанию не входит. Приложению доступны только подключения компании, права берутся от владельца ключа. Запись владелец подтверждает в веб-кабинете, платные вызовы оплачиваются с баланса портала. Пока функция не включена для портала, маршруты отвечают 404 ROUTE_NOT_FOUND. При включённой функции запрещённый ключ, маршрут или операция получают 403 CONNECTOR_KEY_NOT_ALLOWED.

BC-1012-4: Право vibe:storage не выдаётся приложениям Partner Connect

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

Было

Приложение Partner Connect могло получить vibe:storage так же, как vibe:search, vibe:infra и vibe:feedback: право выдавал платформенный администратор проверенному приложению, после чего оно приходило на ключ через согласие пользователя.

Стало

vibe:storage приложению Connect не выдаётся. Ключ, выданный через Connect, попадает в ту же область хранилища, что и личные ключи подключившего пользователя, и с этим правом приложение видело бы все файлы, загруженные его личными ключами. Запрос права при регистрации приложения по-прежнему отклоняется кодом SCOPE_NOT_ALLOWED, а платформенный администратор это право приложению Connect больше не выдаёт. Изменение уже действует. Приложений Connect с этим правом не было, поэтому срок поддержки прежнего порядка не предусмотрен.

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

Не закладывайте хранение файлов на ключ Connect и не запрашивайте vibe:storage в заявке на верификацию. Права Битрикс24, vibe:ai и права, которые выдаёт платформенный администратор, работают как раньше.

FIX-1012-5: Отказ по скоупу vibe:storage у ключа Partner Connect больше не советует выдачу администратором

Было

Когда ключу, выданному через 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 отвечают как раньше. Подробности — Авторизация, ключи и права.

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

Действий не требуется. Если ваш код запускал повторное согласие по этому отказу, для 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 описаны коды 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 возвращает состояние собственного подключения по секрету COMPANY, версии состояния и секрета, доступные возможности и следующее действие. Ответ не содержит персональных данных, секретов и URL и запрещает кэширование. Диагностика доступна для STATUS_ONLY. При ограничении частоты опроса ответ содержит Retry-After. Битрикс24, ИИ и файлы пока закрыты.

NEW-1012-11: Признак размещения приложения в ответах о приложениях

GET /v1/apps, GET /v1/apps/{id} и остальные ответы с объектом приложения, например POST /v1/apps и POST /v1/apps/{id}/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 Вайбкод теперь описывают семь работающих методов ключей управления: GET /v1/keys, POST /v1/keys, GET /v1/keys/{id}, PATCH /v1/keys/{id}, DELETE /v1/keys/{id}, POST /v1/keys/{id}/rotate и GET /v1/portals.

Агенты и генераторы клиентов видят параметры, ответы, отказы и права вызывающего ключа. Методы доступны в срезах vibe:mgmt:keys и vibe:mgmt:portals. Секрет возвращается однократно при создании или ротации, чтение и список содержат только безопасные сведения. Таймаут выпуска ключа теперь отвечает 503 вместо 504, как остальные таймауты платформы, и повторять запрос сразу по-прежнему не нужно. Чтобы добавить методы в генерируемый клиент, обновите его из актуальной спецификации.

NEW-1012-16: Вызовы по расписанию

Появились задачи сервера для вызова HTTP-обработчика приложения по расписанию: GET /v1/infra/servers/:id/jobs — список, POST /v1/infra/servers/:id/jobs — создание, PATCH /v1/infra/servers/:id/jobs/:jobId — замена настроек, DELETE /v1/infra/servers/:id/jobs/:jobId — удаление, POST /v1/infra/servers/:id/jobs/:jobId/run — ручной запуск, GET /v1/infra/servers/:id/jobs/:jobId/runs — журнал запусков и POST /v1/infra/servers/:id/jobs/:jobId/rotate-secret — замена секрета.

Вызов обработчика подписан; повторные попытки одного запуска сохраняют один runId, а результат и попытки видны в журнале. Настройка доступна также через инструмент MCP manage_server_jobs. Документация.

NEW-1012-17: Очистка истории чата для себя или всех

POST /v1/chats/:dialogId/history/clear принимает обязательное поле scope: self очищает историю для вызывающего пользователя, all — для всех участников. Чат сохраняется. Требуются скоуп im и режим доступа с разрешением на запись. Право выполнить операцию проверяет Битрикс24.

Очистка истории возвращает data.result: true только после явного подтверждения. Отсутствие подтверждения даёт 502 BITRIX_UNAVAILABLE.

FIX-1012-18: Подтверждение удаления чата

Было

DELETE /v1/chats/:dialogId мог сообщить об успехе без явного подтверждения удаления со стороны Битрикс24.

Стало

Ответ на подтверждённое удаление по-прежнему имеет статус 200 и содержит data.result: true. Если подтверждение отсутствует, ответ содержит 502 BITRIX_UNAVAILABLE. Запрос не повторяется автоматически после ответа 503 от Битрикс24.

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

Проверяйте состояние чата перед ручным повтором после 502: операция могла уже изменить данные. Успешный ответ на подтверждённое удаление не изменился.

FIX-1012-19: файлы приложения доступны после перевыпуска ключа и передачи приложения

Было

Ключ приложения видел в хранилище только файлы, которые записал владелец этого ключа. После перевыпуска ключа авторизации приложения или передачи приложения другому сотруднику новый ключ отвечал 404 STORAGE_OBJECT_NOT_FOUND на ранее загруженные файлы, а список объектов их не показывал. Повторная загрузка по тому же ключу отвечала 409 STORAGE_KEY_OWNED_ELSEWHERE.

Стало

Файлы принадлежат приложению. Ключ приложения читает, перечисляет и перезаписывает все файлы своего приложения, кто бы их ни загрузил, в том числе после перевыпуска ключа и передачи приложения. GET /v1/storage/objects/{key} для таких файлов снова отвечает перенаправлением на файл. Файлы сотрудника внутри приложения по-прежнему доступны только с токеном этого сотрудника. Личные ключи разработчика работают как раньше.

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

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