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

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

### NEW-0816-1: иконку приложения можно загружать растром, а портал Битрикс24 присылает её сам

Загрузка иконки [POST /v1/infra/servers/:id/icon](/docs/infra/app-icon) принимает не только SVG, но и растровые форматы — PNG, JPG, GIF, WEBP, до 5 МБ и до 4 мегапикселей (например, 2000×2000). Формат определяется по содержимому файла, а не по имени и не по заголовку `Content-Type`. Что бы вы ни загрузили, по URL отдачи иконка по-прежнему возвращается как PNG 256×256: платформа масштабирует изображение в квадрат с сохранением пропорций и прозрачными полями. Прежние вызовы с SVG работают без изменений: ограничения SVG — 256 КБ и прежний потолок в 4096×4096 точек — не менялись.

Новые коды отказа: `ICON_UNSUPPORTED_FORMAT` — формат не распознан или не поддерживается, `ICON_TOO_LARGE` — файл больше допустимого, `ICON_TOO_MANY_PIXELS` — в изображении больше точек, чем платформа берётся распаковать, `ICON_RASTERIZE_FAILED` — файл не удалось прочитать.

Вторая половина изменения — на стороне портала: владелец приложения может сменить иконку прямо в карточке каталога Битрикс24, и портал присылает её на платформу Вайбкод вместе с названием и описанием. Иконка попадает в ту же карточку каталога, что и загруженная через API.

### NEW-0816-2: два поля о временном увеличении лимитов в состоянии Коворк/Код

Ответ [GET /v1/cowork/state](/docs/cowork/state) дополнен парой полей о временном увеличении лимитов: `boostPct` — размер прибавки в процентах (100 означает удвоение), `boostExpiresAt` — момент её окончания. Когда увеличения нет, поля равны `0` и `null`.

Доли использования (`pctUsed`) во всех трёх окнах уже посчитаны с учётом прибавки, поэтому отдельно её применять не нужно — поля нужны, чтобы показать человеку размер и срок.

### NEW-0816-3: новый отказ 402 company_budget_exhausted на вызовах, которые тратят вайбы

**Было**

Единственной причиной отказа по деньгам на `/v1/search/*` и на AI-вызовах была нехватка средств на счету портала — `INSUFFICIENT_BALANCE`. Ограничить расход отдельного сотрудника или всего аккаунта
администратор не мог.

**Стало**

Администратор аккаунта может задать месячный бюджет метрируемого расхода — на весь аккаунт и на
отдельного сотрудника. Когда бюджет исчерпан, вызовы веб-поиска и research, а также AI-вызовы — [POST /v1/chat/completions](/docs/ai/chat/completions), [POST /v1/embeddings](/docs/ai/embeddings) и [POST /v1/audio/transcriptions](/docs/ai/audio/transcriptions) — которые тратят вайбы, получают `402` с кодом
`company_budget_exhausted`.

Тело отказа несёт два дополнительных поля. `scope` говорит, чей бюджет исчерпан: `USER` — личный
бюджет вызывающего, `PORTAL` — бюджет всего аккаунта. `canRequest` говорит, можно ли из продукта
запросить увеличение: для личного бюджета `true`, для бюджета аккаунта `false` — его поднимает
только администратор.

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

Бюджеты включаются отдельно и по умолчанию выключены, поэтому у аккаунтов без них поведение не
меняется.

### FIX-0816-4: выдача ключа деплоя Коворка больше не теряет серверы

**Было**

[POST /v1/cowork/deploy-key](/docs/cowork/deploy-key) отзывал предыдущий ключ, но оставлял на нём всё, что на него ссылалось: владение серверами, карточку приложения и живые токены доступа. Инфраструктурные чтения версионированного API привязаны к вызывающему ключу, поэтому после каждой повторной выдачи прежние серверы пропадали из `GET /v1/infra/servers`, отвечали `404` на запрос по адресу и `403 WRONG_KEY` на публикацию. Вернуть их можно было только через кабинет.

**Стало**

Выдача переносит эти связи на свежий ключ — так же, как это делает ротация ключа. Сразу после ответа список серверов и публикация работают под новым ключом, включая приложения-контейнеры в режиме Галактик.

Вместе с ними переезжает и область видимости запущенных операций, поэтому [GET /v1/infra/operations/{operationId}](/docs/infra/deploy/operation-status) продолжает отдавать исход выкладки, начатой под прежним ключом. Прежде клиент, у которого оборвался транспорт и который поэтому запросил новый ключ, получал `404` на собственную операцию — неотличимо от «такой операции не существует».

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

Менять ничего не нужно: начиная с этой правки повторная выдача ключа связи не теряет.

⚠️ Правка работает вперёд и **не возвращает то, что уже потеряно**. Перенос идёт с ключа, который активен на момент выдачи, а осиротевшие связи лежат на ключах, отозванных раньше, — под этот перенос они не попадают. Если серверы пропали до выката, верните их вручную: в кабинете Вайбкод на карточке сервера выберите привязку к действующему ключу.

Ключ живёт семь дней и по расписанию не перевыпускается. Если к нему не обращались дольше срока, серверы остаются за истёкшим ключом и снова становятся видны после следующей выдачи — она переносит связи уже с него.