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

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

### NEW-0720-1: Ответы приложений теперь возвращают статус публикации

Ответы раздела приложений — [список](/docs/apps/list), [данные приложения](/docs/apps/get), [создание](/docs/apps/create), [публикация](/docs/apps/publish) и [снятие с публикации](/docs/apps/unpublish) — теперь несут два новых поля: `catalogStatus` (`PRIVATE` / `PUBLISHED` / `UNPUBLISHED`) и `publishedAt` (дата публикации, ISO 8601, или `null`). Раньше прочитать статус публикации через V1 было нельзя — приходилось угадывать по массиву `placements`, что ненадёжно: снятое с публикации приложение может сохранить ранее привязанные коды, а `PRIVATE` и `UNPUBLISHED` по `placements` неразличимы. Поля добавлены аддитивно — прежние вызовы работают без изменений.

### FIX-0720-2: переименование чата больше не отвечает ложным успехом тому, кто не участник

**Было**

[PATCH /v1/chats/:chatId](/docs/chats/management/rename), вызванный от имени администратора портала, который не состоит в чате, возвращал `{ "success": true, "data": true }`, хотя название чата не менялось: Битрикс24 отвечал на такой вызов ложным успехом. Отличить его от настоящего переименования по ответу было нельзя, и интегратор считал операцию выполненной. Вызывающий при этом не мог даже прочитать этот чат.

**Стало**

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

### NEW-0720-3: стриминг chat-completions обрывает зависший ответ апстрима явной ошибкой

Если при стриминге ([POST /v1/chat/completions](/docs/ai/chat/streaming) с `stream: true`) апстрим-модель отдала заголовки, но затем замолчала в середине ответа и не присылает новых данных дольше окна ожидания, прокси теперь прерывает вызов и присылает в поток терминальный кадр ошибки перед `data: [DONE]`:

`data: {"error":{"code":"stream_idle_timeout","type":"server_error","retryable":true,"retryAfter":<секунды>}}`

Раньше такой вызов висел бесконечно (агент оставался в состоянии «receiving stream response»). Ошибка повторяемая — прочитайте поток до конца (`[DONE]`) и повторите запрос с учётом `retryAfter`. Обычные (не зависшие) стримы и «думающие» модели, которые непрерывно присылают токены рассуждений, не затронуты.

### NEW-0720-4: tasks: новое поле timeSpentInLogs

Поле `timeSpentInLogs` (фактически затраченное время в секундах, сумма записей учёта времени) теперь задекларировано в схеме задач — доступно в `select`, фильтре и сортировке [GET /v1/tasks](/docs/entities/tasks/list) и `POST /v1/tasks/search`, и присутствует в [GET /v1/tasks/fields](/docs/entities/tasks/fields).

Раньше поле возвращалось, только если в `select` были указаны ОБА написания сразу (`timeSpentInLogs` и `TIME_SPENT_IN_LOGS`); теперь достаточно любого одного. Поле только для чтения — фиксируется через эндпоинт учёта времени, не через обновление задачи.

### FIX-0720-5: GET /v1/files/:id?include=folder теперь возвращает папку

**Было**

[GET /v1/files/:id](/docs/entities/files/get) с `?include=folder` отвечал `200`, но без блока `_included`, хотя [GET /v1/files/fields](/docs/entities/files/fields) объявлял `folder` как includable — включение молча не срабатывало.

**Стало**

`?include=folder` прикрепляет папку в `_included.folder`, как и обещает `/fields`.

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

Действий не требуется. Клиенты, читавшие `_included.folder`, теперь получают объект вместо его отсутствия.

### FIX-0720-6: /v1/me: блок infra стал точным по лимиту серверов, идентификатору провайдера и разбивке

**Было**

`GET /v1/me` в блоке `infra` возвращал `limits.max: 3` независимо от реально применяемого лимита серверов на ключ; `providers` мог отдавать внутренний идентификатор провайдера (расходясь с `GET /v1/infra/providers`) и с возможными дублями; `limits.breakdown` относил виртуальные машины управляемых ботов к `direct` вместо `bots`.

**Стало**

`limits.max` отражает реально применяемый лимит серверов на ключ; `providers` отдаёт публичный идентификатор провайдера, согласованный с `GET /v1/infra/providers`, без дублей; `limits.breakdown` учитывает машины ботов в `bots`. Интеграцию менять не нужно — значения просто стали корректными.

### FIX-0720-7: deal-categories: неизвестные поля фильтра отклоняются, сортировка по id учитывает направление

**Было**

`GET /v1/deal-categories` с фильтром по неизвестному полю молча возвращал ВСЮ таблицу воронок с `200` — Bitrix24 игнорирует неизвестные ключи фильтра legacy-метода и отдаёт весь список. А сортировка `?sort=id&order=desc` игнорировала направление и всегда возвращала один и тот же порядок.

**Стало**

Фильтр по неизвестному или неподдерживаемому полю (а также операторные префиксы `>`/`>=`/`!`/… и операторные объекты) отклоняется до вызова Bitrix24 с `400 UNSUPPORTED_FILTER`; в сообщении перечислены фильтруемые поля (`id`, `name`, `sort`). Фильтр точным совпадением и `$in` по этим полям работают как прежде. Сортировка `?sort=id` теперь корректно учитывает `asc`/`desc`.

### FIX-0720-8: openline-configs: нераспознанные поля в теле записи больше не пропадают молча

**Было**

`POST /v1/openline-configs` (и `PATCH`) молча игнорировал нераспознанные поля тела — Bitrix24 отбрасывает неизвестные ключи метода `imopenlines.config.*`. Тело из одних только неизвестных полей при этом создавало конфигурацию со значениями по умолчанию и отвечало `200`.

**Стало**

Если в теле НЕТ ни одного известного поля — запрос отклоняется с `400 VALIDATION_ERROR` до вызова Bitrix24, и в сообщении перечислены нераспознанные поля. Если известное поле есть, но часть полей нераспознана — запись выполняется как прежде, а в ответе возвращается `meta.warnings` с перечнем проигнорированных полей (раньше они исчезали без следа). Поля только для чтения (`id`, `queue`, `dateCreate` и другие) в теле записи теперь отклоняются с `400 READONLY_FIELD` — раньше они проходили как «известные» и могли привести к созданию конфигурации со значениями по умолчанию.

### FIX-0720-9: GET /v1/{entity}/fields сигналит о неполных метаданных при сбое Bitrix24

**Было**

Если запрос динамических полей к Bitrix24 (`*.fields`) падал (rate-limit, `QUERY_LIMIT_EXCEEDED`, таймаут очереди), эндпоинт молча отдавал 200 только со статическими полями схемы — у многих из них нет человекочитаемой метки (`label`). Ответ выглядел полным, клиент не мог отличить его от корректного и строил недетерминированные маппинги полей.

**Стало**

При сбое запроса полей ответ по-прежнему 200 со статическими полями, но несёт `meta.warnings: [{ "code": "fields_partial", "message": "..." }]` — клиент видит, что набор полей неполный, и может повторить запрос. Формат предупреждения — объект `{ code, message }`, тот же канал и та же форма, что у `meta.warnings` в list/search, поэтому один разбор по `warning.code` работает на всех эндпоинтах.