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

← Журнал изменений · Август 2026

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 отвечает новым полем supportedPlacements у каждого рантайма: ["standalone"] — только отдельная виртуальная машина, ["standalone","galaxy"] — ещё и галактика. Поля name и packages не изменились: они описывают установку на отдельной машине, где комбо-рантайм действительно ставит базу.

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

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

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

Ответ GET /v1/placements получил три необязательных поля. Поле 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 — он создаёт карточку приложения в каталоге приложений Вайбкод на портале Битрикс24. Раньше карточка появлялась только после успешного развёртывания, поэтому приложение, поднятое иначе, в каталоге отсутствовало, и выдача доступа сотрудникам его не показывала.

Вызовы GET /v1/infra/servers и GET /v1/infra/servers/:id теперь отдают блок 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, стоит перечитывать состояние перед решением о блокировке, а не полагаться на то, что доля растёт монотонно.