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

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

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

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

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

Модель появляется в списке [GET /v1/models](/docs/ai/models/list) у порталов, которым генерация открыта, — её отличает `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](/docs/infra/lifecycle/wake), [POST /v1/infra/servers/{id}/start](/docs/infra/lifecycle/start), [POST /v1/infra/servers/{id}/stop](/docs/infra/lifecycle/stop), [POST /v1/infra/servers/{id}/reboot](/docs/infra/lifecycle/reboot), а также автопробуждение внутри [POST /v1/infra/servers/{id}/deploy](/docs/infra/deploy/deploy), [POST /v1/infra/servers/{id}/exec](/docs/infra/deploy/exec), [GET /v1/infra/servers/{id}/logs](/docs/infra/deploy/logs) и [POST /v1/infra/servers/{id}/upload](/docs/infra/deploy/upload). У galaxy-приложения своей машины нет ПО ДИЗАЙНУ, поэтому его прежний ответ не меняется.

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

**Было**

Описание поля `tariff.wasEverCommercial` в [GET /v1/me](/docs/keys-auth/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](/docs/task-history) и [GET /v1/tasks/stages/:entityId](/docs/task-stages), а также `POST /aggregate` у сущностей без полей для группировки: [POST /v1/currencies/aggregate](/docs/entities/currencies/aggregate), [POST /v1/statuses/aggregate](/docs/entities/statuses/aggregate), [POST /v1/deal-categories/aggregate](/docs/entities/deal-categories/aggregate), `POST /v1/calendar-events/aggregate`, `POST /v1/telephony-lines/aggregate` и `POST /v1/humanresources/nodes/aggregate`. Клиент, собранный по спецификации, и ИИ-агент их не находили, хотя первые пять операций описаны на страницах документации. Кроме того, у двухсот с лишним карточек справочника не был указан скоуп, хотя спецификация его объявляла, — среди них все операции разделов «Поиск дубликатов», «История стадий», «Раскладка карточки CRM», «Связи реквизитов» и «Склады». У [POST /v1/products/aggregate](/docs/entities/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`. При отказе ключ не выписывается и прежний проектный ключ остаётся действующим, поэтому запущенные деплои не прерываются.