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

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

### BC-0830-1: Предподписанная single-PUT загрузка временно отключена

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

**Было**

Путь B выдавал предподписанную PUT-ссылку для single-PUT загрузки и публиковал её через `/complete`.

**Стало**

Путь B (создание URL и подтверждение) fail-closed отвечает `503 STORAGE_PRESIGNED_UPLOAD_DISABLED`. Для новых загрузок используйте прямую загрузку (путь A) или multipart (путь C).

### BC-0830-2: переименование приложения больше не отчитывается успехом без подтверждения Битрикс24

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

**Было**

При переименовании через ключ разработчика [PATCH /v1/apps/{id}](/docs/apps/update) снимал прежнюю привязку пункта меню и вешал новую. Если Битрикс24 отклонял новую привязку после успешного снятия, ответ был `502 BITRIX_PARTIAL_REBIND`, а пункт оставался снятым.

На облачном OAuth-пути тот же метод в другом случае вёл себя иначе: если Битрикс24 не подтвердил ни снятие прежней привязки, ни новую, ответ был `200 OK` с предупреждением, и новое имя записывалось. Пункт меню при этом либо исчезал с портала, либо оставался с прежней подписью, а повторный запрос уже не перепривязывал его — платформа считала имя актуальным.

**Стало**

При переименовании через ключ разработчика платформа один раз возвращает прежнюю подпись. Успешно восстановленные места перечислены в новом поле `error.restored` и ручного вмешательства не требуют. Поле `error.unbound` перечисляет места, которые нужно проверить на портале: оставшиеся снятыми, а также те, по которым Битрикс24 не подтвердил снятие. Новые поля `error.bitrixCodes` и `error.bitrixStatuses` передают санитизированную диагностику каждого отклонённого вызова.

Облачный OAuth-путь в случае, когда Битрикс24 не подтвердил ни снятия, ни новой привязки, теперь отвечает `502 BITRIX_PARTIAL_REBIND` и НЕ записывает новое имя.

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

Считайте `502 BITRIX_PARTIAL_REBIND` признаком того, что имя не сохранено, и повторяйте запрос — повтор снова запускает перепривязку. Прежний `200 OK` в этом сценарии успех не означал. Восстанавливать вручную через [POST /v1/placements/bind](/docs/apps/placements/bind) нужно только места из `error.unbound`.

### FIX-0830-3: у моделей `bitrix/*` поток, который не начался, тоже завершается повторяемой ошибкой

**Было**

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

```
data: { "error": { "code": "ai_provider_unavailable", "type": "server_error", "retryable": true, "retryAfter": 6 } }
data: [DONE]
```

**Стало**

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

```
data: { "error": { "code": "stream_idle_timeout", "type": "server_error", "retryable": true, "retryAfter": 7 } }
data: [DONE]
```

Ожидание больше не удваивается невидимо, а причина отказа названа точно. Моделей других поставщиков изменение пока не касается: там установка потока по-прежнему идёт двумя попытками и заканчивается общим `ai_provider_unavailable`.