# Изменения API: 5 июля 2026

[← Журнал изменений](/docs/changelog) · [Июль 2026](/docs/changelog/2026-07)

### FIX-0705-1: Отправка сообщения в чат — понятная ошибка при пустом тексте

Текст сообщения передаётся в поле `message`. Раньше вызов [POST /v1/chats/{dialogId}/messages](/docs/chats/messages/send) с текстом под неизвестным именем поля (например `{"text": "hi"}`) молча отбрасывал это поле, и Битрикс24 возвращал `422 BITRIX_ERROR` о пустом сообщении — хотя контент был передан.

**Было**

`{"text": "hi"}` → `422 BITRIX_ERROR` о пустом сообщении, без указания причины.

**Стало**

Тот же вызов сразу возвращает `400 MESSAGE_REQUIRED` и перечисляет нераспознанные поля, подсказывая поле `message`. Пустой текст по-прежнему допустим вместе с блоком `attach` (сообщение только с вложением).

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

Корректные вызовы с полем `message` не меняются. Ошибка при неверном имени поля стала точной.

### FIX-0705-2: Ключ в заголовке Authorization: Bearer — понятная ошибка вместо INVALID_SESSION

API-ключ передаётся в заголовке `X-Api-Key`. Раньше, если ключ по ошибке клали в `Authorization: Bearer` (это место — для сессионного токена OAuth-приложения), сервер возвращал `401 INVALID_SESSION`, и интегратор искал проблему в OAuth-сессии, хотя причина была в неверном заголовке.

**Было**

Ключ `vibe_app_*` в `Authorization: Bearer` → `401 INVALID_SESSION`.

**Стало**

Тот же запрос возвращает `401 WRONG_AUTH_SCHEME` с подсказкой: ключ OAuth-приложения (`vibe_app_*`) передаётся в `X-Api-Key`, а `Authorization: Bearer` несёт сессионный токен (`vibe_session_*`) из [POST /v1/oauth/token](/docs/keys-auth); клиенту, который умеет только Bearer, подойдёт личный ключ (`vibe_api_*`). Сессионные токены и личные ключи в Bearer не затронуты.

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

Корректные вызовы с ключом в `X-Api-Key` и сессией в `Authorization: Bearer` не меняются.

### FIX-0705-3: multipart/create отклоняет XSS-опасные типы содержимого для PUBLIC-объектов

**Было**

Для `PUBLIC`-объектов типы содержимого `text/html`, `application/javascript`, `application/x-javascript` и `image/svg+xml` отклонялись при прямой и presigned-загрузке, но не при инициализации многочастевой (multipart) загрузки. Вызов [POST /v1/storage/objects/multipart/create](/docs/storage) с `visibility` = `PUBLIC` и таким типом создавал сессию, и после завершения объект отдавался встроенно в браузере.

**Стало**

[POST /v1/storage/objects/multipart/create](/docs/storage) с `visibility` = `PUBLIC` и XSS-опасным типом содержимого возвращает `415 STORAGE_FORBIDDEN_CONTENT_TYPE` — так же, как прямая и presigned-загрузка. Многочастевая сессия при этом не открывается. `PRIVATE`-объекты по-прежнему допускают любой тип содержимого.

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

Поведение приведено к задокументированному в разделе «Хранилище»: XSS-опасные типы содержимого недопустимы для `PUBLIC`-объектов на всех путях загрузки. Чтобы загрузить такой файл многочастевой загрузкой, используйте `visibility` = `PRIVATE` либо безопасный тип содержимого.

### FIX-0705-4: привязка плейсмента на технический адрес сервера теперь ведёт через платформенный обработчик

**Было**

POST /v1/placements/bind принимал `handler`, указывающий на технический Black Hole-адрес приложения (app-*.vibecode…), и регистрировал его в Битрикс24 как есть. Битрикс24 отправлял iframe плейсмента напрямую на этот адрес, минуя платформу: сессия не выпускалась, и на сервере с доступом «только для пользователей Битрикс24» открытие плейсмента зацикливало авторизацию (на публичном сервере приложение отдавало собственную ошибку 404).

**Стало**

Такой `handler` автоматически переписывается на платформенный обработчик приложения (/v1/bitrix-handler) — плейсмент открывается и авторизуется штатно. В ответе появляются `handlerRewritten: true` и `requestedHandler` с исходным значением. Внешние (не Black Hole) обработчики не изменяются. Если платформенный обработчик приложения не удаётся определить, привязка отклоняется с кодом `PLATFORM_HANDLER_UNRESOLVABLE` вместо регистрации нерабочего адреса. Дополнительно GET /v1/placements помечает уже неправильно привязанный обработчик: `data.handlers[].misbound: true` плюс текстовый `warnings[]`.

Кроме того, если плейсмент уже зарегистрирован в Битрикс24, но отсутствует в списке приложения (рассинхрон — например, после снятия с публикации без отвязки в Битрикс24), привязка больше не завершается ошибкой «Handler already binded»: платформа снимает устаревшую привязку и повторяет запрос один раз, восстанавливая рассинхрон. Если же привязка не проходит по другой причине (например, требуется коммерческий тариф Битрикс24), рабочий плейсмент не снимается.

### NEW-0705-5: Новый код ошибки 402 ai_quota_exhausted на AI-эндпоинтах

При включённом контроле месячной AI-квоты портала запросы [POST /v1/chat/completions](/docs/ai/chat/completions), [POST /v1/embeddings](/docs/ai/embeddings) и [POST /v1/audio/transcriptions](/docs/ai/audio/transcriptions) могут вернуть 402 с телом `{ success: false, error: { code: "ai_quota_exhausted", type: "insufficient_quota", reason, resetAt? } }`. Поле `reason` различает три случая: `breaker` — сработал часовой предохранитель расходов сверх квоты, `wallet_empty` — квота исчерпана и на балансе портала нет средств, `wallet_off` — расход сверх квоты для портала недоступен. `resetAt` — момент, когда запросы снова начнут проходить (для `wallet_off` при полном отключении может отсутствовать). Пока квота портала не исчерпана, поведение эндпоинтов не меняется.