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

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

### BC-0716-1: json_object на реасонинг-модели восстанавливает JSON, тело 422 уточнено

> Поддержка старого формата до: 15.01.2027

**Было**

Запрос [POST /v1/chat/completions](/docs/ai/chat/completions) с `response_format` типа `json_object` на модели с рассуждением (например `bitrix/bitrixgpt-5.5-agent`) стабильно возвращал `422 structured_output_truncated`, даже когда модель завершилась сама (`finish_reason: "stop"`) и положила готовый валидный JSON в служебный канал `reasoning_content` — ответ терялся. В теле любой такой ошибки присутствовали поля `error.suggestedMaxTokens` и `error.param`, а текст утверждал «finish_reason=length» независимо от реальной причины остановки.

**Стало**

Если модель на `json_object` завершилась сама и валидный JSON лежит в `reasoning_content`, платформа восстанавливает его и возвращает `200` с этим JSON в `content` (в потоковом режиме — чанком `content` перед терминальным чанком с `finish_reason`). Тело `422` стало правдивым: `error.suggestedMaxTokens` и `error.param` присутствуют **только** при реальной обрезке (`finish_reason: "length"`); при завершении по любой другой причине (`stop` и т.д.) эти поля **опущены**, а текст называет фактический `finish_reason`. Поведение `json_schema` не изменилось — там строгая схема проверяется на стороне модели.

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

Ничего, если вы просто обрабатываете `422` по `error.code`. Если ваш код **безусловно** читает `error.suggestedMaxTokens` или `error.param` на ошибке `structured_output_truncated` — сделайте чтение опциональным: при `finish_reason !== "length"` этих полей теперь нет. Потоковым клиентам с `response_format` — собирать `content` по всем дельтам до `data: [DONE]`.

### FIX-0716-2: env, отправленный файлом в multipart-деплое, больше не игнорируется молча

**Было**

При `multipart/form-data` в [POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy) поле `env`, отправленное как файл или Blob, молча игнорировалось — деплой завершался успехом, но приложение стартовало без переменных окружения.

**Стало**

Такой запрос возвращает 400 с кодом `VALIDATION_ERROR` и подсказкой отправлять `env` текстовым полем с JSON-строкой.

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

Корректный способ (текстовое поле `env` со значением вида `{"KEY":"value"}`) не затронут. Кто отправлял `env` файлом или Blob — теперь получает явную ошибку вместо ложного успеха.

### FIX-0716-3: деплой крупных архивов через source.content больше не падает с Gateway HTTP 413

**Было**

На части порталов [POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy) с `source.content` (base64-архив) падал на шаге `download` с `{ "code": "DEPLOY_FAILED", "message": "Gateway HTTP 413", "step": "download" }`, если base64-тело превышало ~1 МБ (примерно 768 КБ исходного `tar.gz`) — вопреки заявленному лимиту 500 МБ. Обходом была загрузка через `source.url`.

**Стало**

Лимит 500 МБ на inline-загрузку (`source.content` и `multipart`) действует на всех порталах. `source.url` продолжает работать как раньше.

### BC-0716-4: POST /v1/infra/servers отклоняет неизвестные поля в теле

> Поддержка старого формата до: 15.01.2027

**Было**

Неизвестное поле в теле запроса молча игнорировалось. Запрос с `deployMode: "STANDALONE"` (несуществующее поле) возвращал `201` и создавал galaxy-приложение вместо ожидаемого выделенного сервера — правильное поле называется `placement: "dedicated"`.

**Стало**

[POST /v1/infra/servers](/docs/infra/servers/create) отклоняет тело с неизвестным полем ошибкой `400 UNKNOWN_PARAM`. В `details.unknownFields` перечислены лишние поля, в `details.suggestions` — подсказка правильного имени (`deployMode` → `placement`), в `details.validParams` — полный список допустимых полей.

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

Убрать из тела поля, которых нет в списке параметров создания, либо исправить опечатку по подсказке `details.suggestions`. Модель размещения задаётся полем `placement` (`auto` по умолчанию, `dedicated` — отдельная виртуальная машина).

### NEW-0716-5: /v1/sites/fields описывает допустимые значения поля type

`GET /v1/sites/fields` теперь возвращает у поля `type` перечень допустимых значений в `type.enum` с подписями: `PAGE` (лендинг), `STORE` (интернет-магазин), `KNOWLEDGE` (база знаний 2.0), а также `VIBE` (сайт из конструктора) и `SMN` (связка с модулем «Управление сайтом»). Значения `VIBE` и `SMN` встречаются только в ответах и доступны только для чтения — создать сайт такого типа через API нельзя.

### NEW-0716-6: Избранное и закрепление задачи без прав на редактирование

Добавлены четыре ручки для «личных» действий над задачей, которые в Битрикс24 разрешены при доступе только на чтение (не на редактирование): `POST /v1/tasks/:taskId/favorite` добавляет задачу в избранное, `DELETE /v1/tasks/:taskId/favorite` убирает из избранного, `POST /v1/tasks/:taskId/pin` закрепляет задачу в списке задач текущего пользователя, `DELETE /v1/tasks/:taskId/pin` открепляет. Раньше единственным способом изменить задачу был `PATCH /v1/tasks/:id`, который требует прав на редактирование и возвращал «Нет доступа к редактированию задачи», из-за чего разрешённые пользователю действия были недоступны.

### NEW-0716-7: предупреждение о вытесняемом тарифе в ответах пробуждения по расписанию

Ответы [POST /v1/infra/servers/:id/wake-schedules](/docs/infra/wake-schedules/create) и [PATCH /v1/infra/servers/:id/wake-schedules/:scheduleId](/docs/infra/wake-schedules/update) теперь дополнительно несут два поля верхнего уровня: `preemptibleAdvisoryCode` и `preemptibleAdvisory`. Если сервер работает на вытесняемом тарифе, `preemptibleAdvisoryCode` равен `"PREEMPTIBLE_BEST_EFFORT"`, а `preemptibleAdvisory` — краткое английское пояснение того же факта: подъём такого сервера к моменту окна не гарантирован, окно может быть пропущено при нехватке свободной ёмкости. Для сервера на невытесняемом тарифе оба поля — `null`. Предупреждение не блокирует создание или обновление окна — это тот же неблокирующий паттерн, что уже используют поля `tzWarning`/`tzWarningCode`. Старые интеграции, не читающие новые поля, продолжают работать без изменений.
