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

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

### NEW-1021-1: рантайм python312 на Python 3.12 из архива Ubuntu 24.04

Каталог [`GET /v1/infra/runtimes`](/docs/infra/deploy/runtimes) пополнился рантаймами `python312`, `python312-pg`, `python312-mysql`, `python312-redis` и `python312-rag`. На отдельной виртуальной машине Python 3.12 ставится из архива Ubuntu 24.04, а пакеты приложения живут в отдельном окружении платформы: команды `python`, `pip` и `pip3` работают в нём, а `python3` и `python3.12` остаются системным интерпретатором без пакетов приложения. Поэтому в поле `start` для `python312*` пишите `python app.py`, а не `python3 app.py`. В галактике рантайм собирается из официального образа `python:3.12-slim`, где работают обе команды. Рантаймы `python311*` остаются в каталоге и работают как прежде.

### BC-1021-2: Нейтральные идентификаторы и названия образов

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

**Было**

[GET /v1/infra/providers/:providerId/images](/docs/infra/providers/images) мог возвращать внутренние идентификаторы и названия сборок ОС.

**Стало**

Для образов Bitrix Cloud, которые ранее возвращали внутренний идентификатор сборки, `id` теперь содержит семейство `ubuntu-2404-lts`, а `name` — `Ubuntu 24.04 LTS`. Ответ остаётся HTTP 200 с прежними полями. Значения остальных образов не меняются.

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

Передавайте полученный `data[].id` в поле `image` при создании сервера. Не определяйте ОС по внутреннему формату идентификатора и не разбирайте строку `name`. Ранее полученные идентификаторы по-прежнему принимаются при создании сервера.

### NEW-1021-3: APP_DB_BUSY сообщает, что хост галактики запускается

Ответ `409 APP_DB_BUSY` при чтении базы приложения получил необязательное поле `details.hostState`. Оно равно `waking`, пока хост галактики запускается после сна или создания, и отсутствует, когда хост занят другой операцией. Поле приходит в ответах [`GET /v1/infra/servers/{id}/db`](/docs/infra/database/info), [`GET /v1/infra/servers/{id}/db/schema`](/docs/infra/database/schema), [`GET /v1/infra/servers/{id}/db/tables/{table}/rows`](/docs/infra/database/rows) и `POST /v1/infra/servers/{id}/db/query`. Код ошибки, `Retry-After` и признак `retryable` остаются прежними: повторяйте запрос так же, как раньше, и показывайте пользователю, что сервер запускается.

### FIX-1021-4: слишком большой запрос к модели: изображения для bitrix уменьшаются, отказ по размеру — 413 вместо 502

**Было**

[POST /v1/chat/completions](/docs/ai/chat/completions) с моделью `bitrix/*` и телом больше предела кластера моделей отвечал `502 ai_provider_unavailable` — так же, как при сбое модели. Повтор того же запроса снова получал `502`. Так же — `502` вместо отказа по размеру — отвечали и другие методы AI, например [POST /v1/embeddings](/docs/ai/embeddings) и [POST /v1/audio/transcriptions](/docs/ai/audio/transcriptions), когда запрос по размеру отклонял сам провайдер.

**Стало**

Если в теле есть изображения `data:`, платформа уменьшает их сама и отправляет запрос модели. Тело, которое не уложилось в предел 2 MiB и после этого, получает `413 ai_payload_too_large`, сообщение называет размер запроса и действующий предел. Когда платформа уже уменьшает много изображений одновременно, ответ — `429 ai_image_resize_busy` с заголовком `Retry-After`. Запрос к модели не отправляется, списания нет. При `stream: true` оба отказа приходят кадром ошибки с тем же кодом внутри ответа `200`, а пауза для `ai_image_resize_busy` — полем `retryAfter` в кадре. Если по размеру отказал сам провайдер, на любом методе AI, в том числе для моделей на своём ключе провайдера, ответ — `413 ai_payload_too_large` с полем `providerStatusCode: 413`. Уменьшение изображений и проверка до вызова модели действуют только для чата с моделями `bitrix/*`.

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

Запросы, которые укладывались в предел, работают как раньше. Запросы с большими изображениями проходят без изменений на стороне клиента. Повтор после `413` не поможет, после `429` — повторите через `Retry-After`, в потоке — через `retryAfter` из кадра ошибки. Чтобы самим управлять качеством, уменьшайте изображения до 1500 пикселей по длинной стороне. Подробнее — [анализ изображений](/docs/ai/chat/vision).

### NEW-1021-5: Группы, режимы и метаданные каталога коннекторов

[Список коннекторов](/docs/connectors-host) `GET /v1/connectors` принимает `group=all|connected|own|available` и `mode=cowork|code`. Отбор выполняется до страниц. `connected` содержит записи с подключением, `available` — остальные видимые записи; `own` пока пуст. Счетчики групп учитывают остальные фильтры, кроме `group` и `view`. При смене группы или режима начните с первой страницы; пропущенный `group` и `all` используют одинаковые курсоры. Режим поставщика не меняет режим чтения или записи правила доступа.

Поля компании сервиса и разработчика соответствуют карточке: компания сервиса содержит указанные поставщиком название и ссылку либо null, разработчик содержит название и ссылку. Обязательное поле `categories` содержит непустые категории видимого каталога до поиска, фильтров и страниц, в том числе в ответе без параметров списка. Сортировка `sort=popular` учитывает число компаний с активным подключением, без внутренних порталов; данные обновляются раз в сутки. Явные страницы включают число инструментов и отметку популярности. Подключенные коннекторы не получают отметку «Популярно».

### FIX-1021-6: Лимит операций Deploy API считается отдельно для каждого ключа и сервера

**Было**

Запросы без ключа, с неверным ключом или с другим действующим ключом расходовали общий счётчик сервера. Поэтому владелец получал `429 RATE_LIMITED`, даже если сам почти не обращался к серверу. Это затрагивало [POST /v1/infra/servers/:id/exec](/docs/infra/deploy/exec), [POST /v1/infra/servers/:id/upload](/docs/infra/deploy/upload), [POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy), [POST /v1/infra/servers/:id/icon](/docs/infra/app-icon) и [GET /v1/infra/servers/:id/logs](/docs/infra/deploy/logs).

**Стало**

Счётчик ведётся отдельно для пары «API-ключ и сервер». Запросы без ключа или с неверным ключом не расходуют лимит владельца. Другой действующий ключ использует свой счётчик. Порог не менялся: действующее значение приходит в заголовке `x-ratelimit-limit`.

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

Менять интеграцию не требуется. Когда ваш ключ превышает свой порог, ответ по-прежнему содержит `429 RATE_LIMITED` в прежнем формате. Повторите запрос после интервала из заголовка `Retry-After`.

### FIX-1021-7: Примеры запросов и ответов в справочнике API

**Было**

Часть примеров показывала вымышленные поля ответа или запросы, которые API отклонял. Инструкция входа через OAuth предлагала открыть в браузере адрес с секретным ключом приложения.

**Стало**

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

Схемы ответов описывают существующие поля bots, infra и models. Создание шаблона сохраняет служебные поля и адрес скачивания, поля бронирования правильно отмечены как доступные для записи. Пример настройки порта использует допустимый порт приложения.

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

Используйте обновлённые примеры. Поведение API не изменилось. Секретный ключ приложения храните на сервере.

### FIX-1021-8: OpenAPI описывает поля создания записи учёта времени

**Было**

Схема тела `POST /v1/tasks/{taskId}/time` предлагала `commentText`, `dateStart` и `dateStop`, которые обработчик не сохраняет, и не отмечала `seconds` как обязательное поле.

**Стало**

Схема описывает обязательное `seconds` и необязательные `comment`, `userId`, `createdDate`. Дата `createdDate` допускает `YYYY-MM-DD` и ISO 8601 со смещением часового пояса или без него. Обработка запросов не изменилась: исправлено описание уже поддерживаемых полей. При повторной генерации клиента из OpenAPI он получит эти имена полей и обязательное `seconds`.

### FIX-1021-9: регистрация бота обещает повтор только там, где он поможет

**Было**

`POST /v1/bots` и `POST /v1/bots/registrations/{code}/recover` на любой отказ из-за состояния регистрации отвечали HTTP 409 с заголовком `Retry-After: 5`, даже когда повтор не мог помочь. В `error.code` при этом мог приходить служебный код, которого нет в документации.

**Стало**

Коды, описанные для `POST /v1/bots`, приходят с прежним кодом и текстом. У `BOT_REGISTRATION_CONTEXT_CHANGED` и `BOT_REGISTRATION_PROJECTION_CONFLICT` заголовка `Retry-After` больше нет. `BOT_EFFECT_DESIRED_STATE_NOT_PROVED` приходит с `Retry-After`: время до следующей проверки регистрации, если она её ждёт, иначе 30 секунд. У `BOT_RECOVERY_IN_PROGRESS` он прежний. У `BOT_DOMAIN_REREGISTRATION_REQUIRED` он прежний в том ответе, который несёт `data` (сохранённая строка бота с меткой переезда адреса); переезд, обнаруженный в ходе самой регистрации, приходит с тем же кодом, но без `data` и без `Retry-After` — и этот отказ тоже снимается повтором позже, а не поддержкой. Остальные отказы приходят в публичных классах. На `POST /v1/bots` это `BOT_EFFECT_IN_PROGRESS` с тем же правилом `Retry-After`, если регистрация ещё сверяется с Битрикс24, и `BOT_UNAVAILABLE` без `Retry-After`, если состояние регистрации требует исправления через поддержку. На `POST /v1/bots/registrations/{code}/recover` это `BOT_REGISTRATION_RECOVERY_PENDING` с тем же правилом `Retry-After` и `BOT_UNAVAILABLE` без заголовка. Поле `error.details.registrationRef` сохраняется в обоих ответах восстановления. Коды и правила заголовка описаны в ответе `409` обоих методов в OpenAPI-схеме `GET /v1/openapi.json?scope=imbot`.

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

Ничего менять не нужно. Клиент, который обрабатывает `409`, повторяет вызов при наличии `Retry-After`; единственный отказ, который стоит повторить и без заголовка, — `BOT_DOMAIN_REREGISTRATION_REQUIRED` без `data`: это идущая перерегистрация после смены адреса. При `BOT_UNAVAILABLE` обратитесь в поддержку и передайте `registrationRef`, если он есть в ответе.