Изменения API: 19 сентября 2026

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

NEW-0919-1: генерация изображений моделью BitrixGPT 5.6 Image

Появился POST /v1/images/generations — создание картинки по текстовому описанию моделью bitrix/bitrixgpt-5.6-image. Формат запроса и ответа совместим с OpenAI API: одна картинка за вызов приходит в поле data[0].b64_json в формате base64. Платформа изображения не хранит и ссылок на них не выдаёт.

Картинка учитывается в AI-квоте портала: в рамках квоты тарифа деньги с баланса не списываются, сверх квоты каждая картинка оплачивается с баланса портала по цене из поля pricing.perCall модели. Неудачный вызов не оплачивается.

Модель появляется в списке GET /v1/models у порталов, которым генерация открыта, — её отличает capabilities.image_generation. Остальным порталам ручка отвечает 404.

FIX-0919-2: потерянная связь с виртуальной машиной больше не выдаётся за её отсутствие и не советует создать вторую

Было

Любая операция над сервером, у которого в записи нет указателя на виртуальную машину, — пробуждение, запуск, остановка, перезагрузка, ресайз и автопробуждение внутри деплоя, выполнения команды, чтения логов и загрузки файлов — всегда отвечала 422 VM_MISSING с текстом «удалите этот сервер и создайте новый», а пробуждение добавляло подсказку «утечки не будет — освобождать нечего» и переводило запись в статус error. Пустой указатель, однако, означает только то, что указателя нет В ЗАПИСИ: если он не записался в момент создания сервера, машина существует, работает и тарифицируется. Совет удалить и пересоздать в этом случае приводил к тому, что клиент заводил вторую машину, а первая оставалась работать уже без всякой записи — то есть подсказка сама порождала утечку.

Стало

Перед вынесением вердикта платформа сверяется со своим разбором облака, и делает это ОДИНАКОВО на всех дверях. Если разбор видит машину под облачным именем этого сервера, ответ — 422 с НОВЫМ кодом VM_POINTER_LOST: связь с машиной потеряна, машина скорее всего работает и тарифицируется, удалять сервер и создавать новый НЕ нужно, случай виден платформе и решается через поддержку. Операция при этом всё равно не выполняется — без указателя она невозможна, — но запись в error НЕ переводится и остаётся в прежнем статусе. Когда разбор машины под этим именем не видит, ответ прежний — 422 VM_MISSING с прежним текстом и прежними побочными эффектами. Разбор облака обновляется раз в час, поэтому запись, которую он ещё не догнал, получает прежний ответ VM_MISSING.

Затронутые эндпоинты: POST /v1/infra/servers/{id}/wake, POST /v1/infra/servers/{id}/start, POST /v1/infra/servers/{id}/stop, POST /v1/infra/servers/{id}/reboot, а также автопробуждение внутри POST /v1/infra/servers/{id}/deploy, POST /v1/infra/servers/{id}/exec, GET /v1/infra/servers/{id}/logs и POST /v1/infra/servers/{id}/upload. У galaxy-приложения своей машины нет ПО ДИЗАЙНУ, поэтому его прежний ответ не меняется.

FIX-0919-3: признак `wasEverCommercial` в `GET /v1/me` — история оплат, а не доступ

Было

Описание поля tariff.wasEverCommercial в GET /v1/me и MCP-справка для агентов (промпт upgrade-from-trial, справочник vibe://tariff-gate-reference) подавали признак как доверие: будто портал, который когда-либо был на коммерческом тарифе, сохраняет доступ после понижения тарифа и остановить его может только баланс, а OPEN-режим он получает в обход проверки тарифа.

Стало

Описания приведены к поведению платформы, которое действует с 02.09.2026: признак лишь фиксирует, что портал когда-либо наблюдался на коммерческом тарифе. Доступа к инфраструктуре и к OPEN-режиму он не даёт и отказов не снимает — доступ определяется текущим тарифом, подпиской и демо. Ответы API не изменились.

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

Не ветвитесь по wasEverCommercial. Доступность операции читайте из capabilities того же ответа, причину отказа — из кода ошибки.

NEW-0919-4: режим работы сервера и библиотека расписаний теперь доступны по API

Режим машины, который ответы V1 уже показывают (runMode, workSchedule), теперь можно и задать ключом. PATCH /v1/infra/servers/{id}/run-mode принимает {"mode":"ALWAYS"}, {"mode":"IDLE","idleMinutes":30} или {"mode":"SCHEDULE","scheduleId":"..."} и отвечает тем же объектом режима, что и чтение.

Библиотека расписаний открыта целиком: GET/POST /v1/work-schedules и GET/PATCH/DELETE /v1/work-schedules/{id}, окна — [{"isoDay":1,"start":"09:00","end":"18:00"}] в часовом поясе самого расписания. Библиотека общая на портал, поэтому правка несёт version и отвечает 409 WORK_SCHEDULE_STALE, если расписание успели изменить. Готовое расписание не редактируется (403 WORK_SCHEDULE_PRESET_READONLY). Расписание с назначенными машинами удаляется только с ?reassign=true — приложения переходят в сон по простою, агенты и боты в круглосуточный режим, а без согласия ответ 409 WORK_SCHEDULE_IN_USE. У хоста галактики своего режима нет (400 GALAXY_NOT_SUPPORTED), а пока режимы на портал не раскатаны, запись отвечает 400 RUN_MODE_UNAVAILABLE. Прежние запросы, включая PATCH /v1/infra/servers/{id}/sleep, работают как раньше.

FIX-0919-5: спецификация OpenAPI и справочник API описывают историю задачи, стадии канбана и агрегацию справочников CRM

Было

Машинная спецификация GET /v1/openapi.json и справочник API не содержали работающих операций GET /v1/tasks/:taskId/history и GET /v1/tasks/stages/:entityId, а также POST /aggregate у сущностей без полей для группировки: POST /v1/currencies/aggregate, POST /v1/statuses/aggregate, POST /v1/deal-categories/aggregate, POST /v1/calendar-events/aggregate, POST /v1/telephony-lines/aggregate и POST /v1/humanresources/nodes/aggregate. Клиент, собранный по спецификации, и ИИ-агент их не находили, хотя первые пять операций описаны на страницах документации. Кроме того, у двухсот с лишним карточек справочника не был указан скоуп, хотя спецификация его объявляла, — среди них все операции разделов «Поиск дубликатов», «История стадий», «Раскладка карточки CRM», «Связи реквизитов» и «Склады». У POST /v1/products/aggregate спецификация обещала фильтр с операторами, тогда как операция принимает только точное совпадение, как и поиск товаров.

Стало

Все восемь операций описаны в спецификации и справочнике. Для сущностей без полей для группировки описание агрегации называет то, что операция принимает: count по "*" и числовые функции по числовым полям сущности, без groupBy. Где фильтр сущности ограничен — только точное совпадение или только отдельные ключи, — фильтр агрегации описан тем же перечнем допустимых ключей, что у поиска. Ключи фильтра, которые передаются параметрами вызова и без которых операция отвечает MISSING_REQUIRED_PARAMS, в спецификации отмечены как обязательные, а пример в карточке справочника их передаёт. Карточка справочника показывает скоуп, объявленный спецификацией. Поведение операций не изменилось.

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

Никакого: запросы и ответы прежние. Клиент, сгенерированный по спецификации, после обновления получит методы для этих восьми операций.

BC-0919-6: проектный ключ деплоя выдаётся только допущенному порталу

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

Было

POST /v1/cowork/deploy-key спрашивал скоуп ключа, платформенные выключатели и наличие места Cowork/Code — и на этом останавливался. Портал без действующей подписки BitrixGPT + Маркетплейс получал рабочий проектный ключ, хотя на выписке такого же ключа из кабинета платформа Вайбкод отвечала ему отказом. Сотрудник, которому портал запретил создавать серверы, ключ тоже получал и упирался в отказ уже на первом вызове POST /v1/infra/servers.

Стало

Перед выдачей маршрут спрашивает те же две двери, что кабинет и создание сервера: допуск портала к платформе и политику портала по серверам. Портал без подписки получает 402 с кодом MARKETPLACE_REQUIRED, а там, где доступ даёт тариф Битрикс24, — KZ_PAID_ONLY, UZ_PAID_ONLY, BY_PAID_ONLY или INT_TARIFF_REQUIRED. Если платформа не смогла прочитать подписку или тариф портала, ответ — 403 PORTAL_SUBSCRIPTION_UNREADABLE или 403 PORTAL_TARIFF_UNREADABLE, и покупка такой отказ не снимает. Портал с отключённой инфраструктурой получает 403 INFRA_NOT_PERMITTED, сотрудник вне политики — 403 SERVER_CREATION_DISABLED или 403 SERVER_CREATION_ADMINS_ONLY. При отказе ключ не выписывается и прежний проектный ключ остаётся действующим, поэтому запущенные деплои не прерываются.