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

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

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

Каталог GET /v1/infra/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 мог возвращать внутренние идентификаторы и названия сборок ОС.

Стало

Для образов 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, GET /v1/infra/servers/{id}/db/schema, GET /v1/infra/servers/{id}/db/tables/{table}/rows и POST /v1/infra/servers/{id}/db/query. Код ошибки, Retry-After и признак retryable остаются прежними: повторяйте запрос так же, как раньше, и показывайте пользователю, что сервер запускается.

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

Было

POST /v1/chat/completions с моделью bitrix/* и телом больше предела кластера моделей отвечал 502 ai_provider_unavailable — так же, как при сбое модели. Повтор того же запроса снова получал 502. Так же — 502 вместо отказа по размеру — отвечали и другие методы AI, например POST /v1/embeddings и POST /v1/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 пикселей по длинной стороне. Подробнее — анализ изображений.

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

Список коннекторов 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, POST /v1/infra/servers/:id/upload, POST /v1/infra/servers/:id/deploy, POST /v1/infra/servers/:id/icon и GET /v1/infra/servers/:id/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, если он есть в ответе.