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

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

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} снимал прежнюю привязку пункта меню и вешал новую. Если Битрикс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 нужно только места из 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.