# Изменения API: 15 августа 2026

[← Журнал изменений](/docs/changelog) · [Август 2026](/docs/changelog/2026-08)

### BC-0815-1: комбо-рантаймы с базой данных больше не проезжают в галактику молча

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

**Было**

Деплой приложения в галактику с рантаймом, обещающим базу данных (`node20-pg`, `node20-mysql`, `node20-redis`, `node20-mysql-redis`, `node20-pg-redis`, `node20-rag`, `python311-pg`, `python311-mysql`, `python311-redis`, `python311-rag`, `php83-mysql`), завершался успехом. Суффикс базы срезался, приложение получало только языковой образ: ни СУБД, ни переменных подключения (`DATABASE_URL`, `PG*`). Ошибка всплывала при первом обращении к базе.

**Стало**

Такой деплой отклоняется сразу: `400` с кодом `GALAXY_RUNTIME_DB_UNSUPPORTED`, полем `details.suggestedRuntime` (языковая замена — например `node20` вместо `node20-pg`) и подсказкой по восстановлению. Каталог [GET /v1/infra/runtimes](/docs/infra/deploy/runtimes) отвечает новым полем `supportedPlacements` у каждого рантайма: `["standalone"]` — только отдельная виртуальная машина, `["standalone","galaxy"]` — ещё и галактика. Поля `name` и `packages` не изменились: они описывают установку на отдельной машине, где комбо-рантайм действительно ставит базу.

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

Перед деплоем в галактику фильтруйте каталог по `supportedPlacements` со значением `galaxy`. Приложению в галактике нужна база — возьмите языковой рантайм и передайте строку подключения к внешней базе через `env`. Нужна база на той же машине — создайте отдельную виртуальную машину (`placement: "dedicated"`, создание без `source`) и задеплойте на неё исходный рантайм вторым шагом. Уже работающие приложения не затронуты: отказ возникает только на новом деплое.

### NEW-0815-2: список привязанных мест сообщает, сверялись ли с аккаунтом

Ответ [GET /v1/placements](/docs/apps/placements/list) получил три необязательных поля. Поле `portalSync` говорит, чем закончилась сверка перечня с аккаунтом Битрикс24: `ok` — аккаунт вернул все привязанные коды, `drift` — часть кодов аккаунт не вернул, `unknown` — сверки не было. Причина значения, отличного от `ok`, приходит в `portalSyncReason` — `no_oauth_session`, `empty_vibe_list`, `b24_unreachable`, `unpublished` или `missing_on_portal`. При расхождении коды, которые числятся привязанными в Вайбкод и не вернулись от аккаунта, перечислены в `missingOnPortal`, и на них же появляется строка в `warnings`.

Приложение, снятое с каталога, расхождением не считается: значение `unpublished` говорит, что места на аккаунте сняла сама платформа, а коды сохранены для повторной публикации. Сверка выполняется, когда вместе с ключом приложения передан токен сессии и у приложения есть привязанные места. Без этих условий поле `portalSync` приходит со значением `unknown` — прежнее поведение ответа не менялось, просто теперь оно названо явно.

Раньше исход сверки приходилось выводить из наличия и длины массива `handlers`, а это не различало «аккаунт ответил и кода в ответе нет» и «ответ аккаунта получить не удалось»: в обоих случаях приходил пустой массив. Теперь во втором случае поле `handlers` не приходит вовсе, а причина видна в `portalSyncReason`. Прежние вызовы продолжают работать, новые поля дополняют ответ.

### FIX-0815-3: квота ИИ считается по тарифу во всех западных зонах

**Было**

Тариф аккаунта Битрикс24 записывается как «зона аккаунта плюс редакция» — например
`jp_pro100`. Приставку зоны платформа снимала не у всех: из западных зон разбирались
только десять, и аккаунт в зоне `cn`, `id`, `it`, `vn`, `jp`, `ms`, `th`, `hi`, `co`
или `ae` не совпадал ни с одной настройкой тарифа. Такому аккаунту месячная квота ИИ
считалась по резервному правилу, а не по его тарифу.

**Стало**

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

### NEW-0815-4: приложение можно опубликовать в каталоге Битрикс24 отдельным вызовом

Появился вызов [POST /v1/infra/servers/:id/b24-catalog/publish](/docs/infra/servers/b24-catalog-publish) — он создаёт карточку приложения в каталоге приложений Вайбкод на портале Битрикс24. Раньше карточка появлялась только после успешного развёртывания, поэтому приложение, поднятое иначе, в каталоге отсутствовало, и выдача доступа сотрудникам его не показывала.

Вызовы [GET /v1/infra/servers](/docs/infra/servers/list) и [GET /v1/infra/servers/:id](/docs/infra/servers/get) теперь отдают блок `b24CatalogSync` с полями `status`, `itemId`, `attempts`, `pendingOp` и `eligible`. Признак «приложение в каталоге» — непустой `itemId`. Поле `eligible` отвечает на другой вопрос: может ли карточка существовать в принципе — у рантайма агента, хоста галактики, сервера без субдомена и сервера, на который ещё не выкладывали приложение, её не будет.

Прежние вызовы работают без изменений: правка политики доступа и списка доступа карточку по-прежнему не создаёт, она обновляет уже существующую.

### FIX-0815-5: месячный лимит Коворка догоняет тарифную сетку без ожидания продления

**Было**

`/v1/cowork/state` и `/v1/cowork/me` считали месячное окно платного места от
объёма, зафиксированного в момент покупки. Когда месячный лимит тарифа
увеличивался, новое значение доезжало до места только на
следующем продлении: доля `month.pctUsed` не менялась, а место, упёршееся в
`exhausted`, оставалось заблокированным до конца оплаченного периода, хотя
лимит тарифа уже вырос. Недельное и пятичасовое окна при этом обновлялись
сразу — три окна одного места отвечали по разным правилам.

**Стало**

Месячное окно платного места считается от большего из двух: действующего лимита
тарифа и объёма, проданного на текущий период. Увеличение лимита применяется
сразу — `month.pctUsed` падает без единого запроса, а `month.exhausted`
сбрасывается в `false`, если новый лимит выше израсходованного. Уменьшение
лимита оплаченный период не затрагивает: до его конца место считается по
проданному объёму, новое значение вступает в силу со следующего периода.
Бесплатное место, как и раньше, считается строго по действующему лимиту.

Абсолютных чисел в ответе по-прежнему нет — меняются только доли, признак
`exhausted` и момент `resetAt`. Клиенту, кэширующему `month.pctUsed`, стоит
перечитывать состояние перед решением о блокировке, а не полагаться на то, что
доля растёт монотонно.