# Изменения API: 8 октября 2026 [← Журнал изменений](/docs/changelog) · [Октябрь 2026](/docs/changelog/2026-10) ### FIX-1008-1: установка Python 3.11 продолжает работу при недоступности репозитория **Было** Развёртывание отдельного сервера с рантаймом Python 3.11 могло завершиться ошибкой, если репозиторий пакетов не отвечал. **Стало** Установка Python 3.11 пробует запасной проверенный источник. После успешного развёртывания доступны `python3.11` и `pip` для Python 3.11; системный `python3` остаётся прежним. ### FIX-1008-2: SSH-ключ пользователя устанавливается на заранее подготовленную виртуальную машину **Было** `POST /v1/infra/servers` мог выдать заранее подготовленную виртуальную машину без переданного в `sshPublicKey` ключа пользователя. **Стало** При успешном создании платформа устанавливает этот ключ и на заранее подготовленную машину. Для входа по SSH можно использовать свой ключ; поля SSH-ключа в ответе по-прежнему содержат ключ платформы. ### NEW-1008-3: Вход в Коворк по ссылке со страницы Вайбкод **Было:** настольный Коворк начинал вход только сам — по коду устройства или через браузер. **Стало:** страница Коворка на платформе Вайбкод выпускает одноразовую ссылку `openwork://vibecode-auth?grant=<код>`. Клиент `cowork-desktop` может сначала просмотреть, кому принадлежит код, через `POST /v1/connect/desktop-handoff/preview`, затем обменять его на ключ через `POST /v1/connect/token` с типом `urn:vibecode:params:oauth:grant-type:desktop-handoff` и необязательным `device_id`. Код живёт 120 секунд и обменивается один раз. Ответ об обмене содержит `api_key`, `scopes` и, если данные доступны, `granted_scopes` и `b24_credentials`. Прежние ключи установки гасит не обмен, а подтверждение доставки `POST /v1/connect/desktop-handoff/confirm` с новым ключом: потерянный ответ обмена не оставляет установку без входа. Если у пары «сотрудник — портал» уже 10 живых ключей Коворка, а `device_id` новый, обмен отвечает `409 access_denied` с `COWORK_DEVICE_LIMIT_REACHED`; код при этом потрачен, нужна новая ссылка. `device_id` в обмене кода необязателен, но без него подтверждение доставки прежние ключи установки не гасит, а при лимите в 10 ключей обмен освобождает место, отзывая давно не использовавшийся ключ без `device_id` — передавайте его всегда. Если вход по коду выключили уже после обмена, подтверждение отвечает `404 not_found` / `COWORK_DESKTOP_HANDOFF_UNAVAILABLE` и ничего не гасит. Сотрудник, уволенный в Битрикс24 (`b24Active=false`), кода не обменивает и не просматривает: `409 B24_USER_DELETED`. Ошибка `temporarily_unavailable` (`503`) теперь входит в схему `OAuthError`. Подтверждение доставки принимается сутки после истечения кода: позже — `400 invalid_grant`, прежние ключи не гасятся. При выключенном входе по коду просмотр и подтверждение отвечают `404`, а обмен — `unsupported_grant_type` раньше проверки клиента. Обмен при лимите устройств отвечает `409 COWORK_DEVICE_LIMIT_REACHED`. ### FIX-1008-4: OpenAPI описывает чтение писем, действия с ними и поиск адресатов **Было** Восемь работающих почтовых методов отсутствовали в OpenAPI и справочнике API Вайбкод: [чтение письма](/docs/mail/messages/get), [цепочка писем](/docs/mail/messages/thread), [перемещение писем](/docs/mail/messages/move), [ответ](/docs/mail/messages/reply) и [пересылка](/docs/mail/messages/forward), создание [задачи](/docs/mail/conversions/task), [события](/docs/mail/conversions/calendar-event), [чата](/docs/mail/conversions/chat), [поста](/docs/mail/conversions/feed-post) и [дела CRM](/docs/mail/conversions/crm-activity-create) из письма, [удаление дела CRM](/docs/mail/conversions/crm-activity-delete), поиск [контактов](/docs/mail/recipients/contacts) и [сотрудников](/docs/mail/recipients/employees) для адресации. Генераторы клиентов и агенты, читающие спецификацию, этих методов не видели. **Стало** Методы включены в полную спецификацию, срез `mail` и справочник на обоих языках. Поведение методов не изменилось. Чтобы методы появились в генерируемом клиенте, обновите его из актуальной спецификации. **Влияние на интеграторов** Действий не требуется. ### FIX-1008-5: OpenAPI описывает подсчёт, поиск и операции с оргструктурой **Было** Десять работающих методов оргструктуры отсутствовали в OpenAPI и справочнике API Вайбкод: [подсчёт сотрудников](/docs/humanresources/employees/count), [подчинённые сотрудника](/docs/humanresources/employees/subordinates), [поиск сотрудников](/docs/humanresources/employees/search), [сотрудники в нескольких отделах](/docs/humanresources/employees/multidepartment), [подсчёт узлов](/docs/humanresources/node-operations/count), [дочерние узлы](/docs/humanresources/node-operations/children), [чтение](/docs/humanresources/node-operations/communications-get) и [настройка средств связи](/docs/humanresources/node-operations/communications-set), операции с участниками узла — [добавление](/docs/humanresources/members/add), [удаление](/docs/humanresources/members/remove), [перемещение](/docs/humanresources/members/move) и [замена состава](/docs/humanresources/members/set), а также [перемещение узла](/docs/humanresources/node-operations/move). Генераторы клиентов и агенты, читающие спецификацию, этих методов не видели. **Стало** Методы включены в полную спецификацию, срез `humanresources` и справочник на обоих языках. Поведение методов не изменилось. Чтобы методы появились в генерируемом клиенте, обновите его из актуальной спецификации. **Влияние на интеграторов** Действий не требуется. ### FIX-1008-6: OpenAPI описывает свои ключи ИИ и их модели **Было** Одиннадцать работающих методов своих ключей ИИ отсутствовали в OpenAPI и справочнике API Вайбкод: [список ключей](/docs/ai/credentials/list), [подключение](/docs/ai/credentials/create), [обновление](/docs/ai/credentials/update), [удаление](/docs/ai/credentials/delete), [проверка](/docs/ai/credentials/test), [статистика](/docs/ai/credentials/usage), [загрузка моделей](/docs/ai/credentials/fetch-models), [список моделей](/docs/ai/credentials/models-list), [добавление модели](/docs/ai/credentials/models-add), [удаление модели](/docs/ai/credentials/models-delete) и [список провайдеров](/docs/ai/credentials/providers). Агенты и генераторы клиентов, читающие спецификацию, не видели эти методы. **Стало** Методы включены в полную спецификацию, срез `vibe:ai` и справочник на обоих языках. Описаны поля запросов, ответы и отказы; секреты ключей провайдеров в ответах не возвращаются. Поведение методов не изменилось. Чтобы методы появились в генерируемом клиенте, обновите его из актуальной спецификации. **Влияние на интеграторов** Действий не требуется. ### BC-1008-7: ключ партнёрского приложения не передаёт vibe:ai производному ключу — 403 SCOPE_GRANT_REQUIRES_CONSENT > Поддержка старого формата до: не предусмотрена **Было** Ключ, выданный приложению партнёра через Partner Connect с правом `vibe:ai`, мог создать приложение через `POST /v1/apps` с `vibe:ai` в `scopes` или добавить `vibe:ai` через `PATCH /v1/apps/:id`, и парный ключ приложения получал это право. **Стало** `POST /v1/apps` и `PATCH /v1/apps/:id` с `vibe:ai` от ключа партнёрского приложения отвечают `403 SCOPE_GRANT_REQUIRES_CONSENT`, в `error.details.unconsented` приходит `["vibe:ai"]`, ничего не создаётся и не меняется. Парный ключ, созданный ключом партнёра, `vibe:ai` не получает. Ключи сотрудников и ключ устройства Cowork/Code правило не затрагивает. **Что делать интеграторам** Не запрашивайте `vibe:ai` для приложений, которые создаёт ключ Partner Connect: модели вызывайте самим ключом Partner Connect. Разбор — [Создать приложение](/docs/apps/create). ### NEW-1008-8: Partner Connect: пример кнопки «Подключить ИИ» для приложения внутри Битрикс24 На странице [Partner Connect](/docs/partner-connect#подключение-ai-из-приложения-внутри-битрикс24) появился готовый пример: кнопка во фрейме приложения открывает страницу согласия в отдельном окне браузера, а фрейм забирает результат со своего сервера. Встроить страницу согласия во фрейм портала нельзя. Предупреждение для партнёров: ключ приложения, выданный через Partner Connect, перестанет управлять ключами внешних моделей — `/v1/ai/credentials` со вложенными маршрутами и `/v1/ai/providers` будут отвечать ему `403 INSUFFICIENT_SCOPE`. Вызовы моделей тем же ключом не меняются. Пока ответы этих маршрутов прежние, дату перехода объявит отдельная запись журнала. ### NEW-1008-9: Бот без активной подписки объясняет причину остановки и даёт ссылку на оформление В ответе HTTP 403 `B24_MARKET_SUBSCRIPTION_REQUIRED` появились необязательные поля `error.userMessage` и `error.upgradeUrl`. Текст объясняет владельцу портала, что бот остановлен из-за неактивной подписки и администратору нужно оформить или продлить её. Ссылка ведёт на оформление подписки на портале Битрикс24; если домен портала недоступен, ссылка не возвращается. Код ошибки, статус HTTP 403, `retryable: false`, `retryAfterSeconds: 3600` и заголовок `Retry-After: 3600` сохранены. ### FIX-1008-10: OpenAPI описывает поля шаблонов реквизитов **Было** Семь работающих методов полей шаблонов реквизитов отсутствовали в OpenAPI и справочнике API Вайбкод: [список полей](/docs/entities/requisite-presets/preset-fields/list), [схема](/docs/entities/requisite-presets/preset-fields/schema), [доступные поля](/docs/entities/requisite-presets/preset-fields/available), [добавление](/docs/entities/requisite-presets/preset-fields/create), [чтение](/docs/entities/requisite-presets/preset-fields/get), [обновление](/docs/entities/requisite-presets/preset-fields/update) и [удаление](/docs/entities/requisite-presets/preset-fields/delete). Агенты и генераторы клиентов, читающие спецификацию, не видели эти методы. **Стало** Методы включены в полную спецификацию, срез `crm` и справочник на обоих языках. Описаны параметры, поля запросов, ответы и отказы. Поведение методов не изменилось. Чтобы методы появились в генерируемом клиенте, обновите его из актуальной спецификации. **Влияние на интеграторов** Действий не требуется. ### FIX-1008-11: Доступность методов Диска **Было:** запросы к `/v1/disk/*` могли возвращать `403 DISK_FEATURE_DISABLED` при действующем ключе со скоупом `disk`. **Стало:** методы доступны без отдельного включения на платформе. Сохранены аутентификация, проверка скоупа `disk`, текущих прав и режима ключа. Поддержку поиска, синхронизации и сохранения проверяйте через `GET /v1/disk/capabilities`. ### BC-1008-12: принудительное удаление бота требует подтверждения Bitrix24 > Поддержка старого формата до: не предусмотрена **Было** [DELETE /v1/bots/{botId}](/docs/bots/management/delete) с `force=true` мог отвечать HTTP 200 и удалять запись бота, даже когда удаление в Bitrix24 не было подтверждено. **Стало** Если удаление в Bitrix24 не подтверждено, ответ — HTTP 409 `BOT_DELETE_PENDING` с `Retry-After`. Запись бота сохраняется для повторной попытки. При подтверждённом удалении успешный ответ HTTP 200 сохраняется. **Что делать интеграторам** При `BOT_DELETE_PENDING` не считайте бота удалённым; повторите запрос после `Retry-After` и дождитесь успешного ответа. ### FIX-1008-13: удаление ключа дожидается очистки бота **Было** `DELETE /v1/keys/{id}` возвращал `409 KEY_HAS_LINKED_AGENT`, если ключ был связан с отдельным ботом. Удаление бота требовало отдельного запроса. **Стало** Для ключа без действующего агента или управляемого бота удаление запускает очистку связанного бота в Bitrix24. Пока очистка не подтверждена, ответ — `409 KEY_BOT_CLEANUP_PENDING`; ключ и бот сохраняются. Повторите запрос после завершения очистки. ### BC-1008-14: пакетный список одной сущности применяет сортировку > Поддержка старого формата до: не предусмотрена **Было** Действие `list` в [POST /v1/{entity}/batch](/docs/entity-api) не читало `sort` и `order`. Подзапрос с сортировкой отвечал успехом, но строки приходили в порядке Битрикс24, у сделок и других сущностей CRM — по возрастанию `id`. Ошибок и предупреждений не было. Тот же порядок через общий `POST /v1/batch` у этих сущностей применялся. **Стало** Подзапрос `list` читает `sort` и `order`, переводит оба написания в имена полей Битрикс24 и передаёт порядок в Битрикс24. Если переданы оба параметра, порядок задаёт `sort`, а `order` всё равно проверяется. Сортировка, которую сущность принять не может, отклоняется ошибкой в своём подзапросе до обращения к Битрикс24, соседние подзапросы выполняются: неверное направление — `INVALID_SORT_DIRECTION`, незнакомое поле у сущностей, у которых проверка имён сортировки включена, — `UNKNOWN_SORT_FIELD`, сортировка у сущностей, которые её в подзапросе не поддерживают (`departments`, `telephony-lines`, `calendar-resources`, `calendar-events`, `doc-templates`), — `INVALID_SORT_FIELD`. Шаблоны документов сортирует одиночный `GET /v1/doc-templates?sort=…`, события календаря приходят упорядоченными по времени начала. У `users` порядок передаётся одним полем, и действует предупреждение `SORT_FALLBACK_TO_ID`, как в общем пакете. **Что делать интеграторам** Если подзапрос передавал сортировку, которую теперь отклоняет ошибка, — исправьте направление или имя поля, а у сущностей без сортировки уберите параметр: он никогда не применялся. Подзапросы без сортировки работают как раньше. Параллельная поддержка прежнего поведения не предусмотрена: параметр молча игнорировался, сохранять нечего.