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

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

### NEW-0623-10: подсказка по настройке push-доставки в ошибках подписки на события

Ответы об ошибке `400 NOT_OAUTH_APP` и `400 NO_USER_TOKEN` у [POST /v1/infra/servers/:id/event-subscriptions](/docs/infra/event-subscriptions) теперь содержат поле `error.hint` — текстовую инструкцию, как получить сервер под ключом авторизации (`vibe_app_`) для push-доставки: создать ключ авторизации через `POST /v1/apps`, авторизовать приложение на портале, создать новый сервер под этим ключом. Отдельной «миграции» существующего сервера с обычного ключа нет. Поле аддитивное — прежние клиенты не затронуты.

### FIX-0623-1: список действий бизнес-процессов

**Было**

[GET /v1/bizproc-activities](/docs/entities/bizproc-activities) возвращал каждый код действия как объект с числовыми ключами по символам — например, `{"0":"D","1":"i", …}` вместо строки `"DiskRead"`. Проверка `Array.includes(code)` не работала.

**Стало**

Эндпоинт возвращает коды действий массивом строк, как и задокументировано.

### FIX-0623-2: ключи ответа поиска дубликатов в camelCase

**Было**

`POST /v1/duplicates/find` возвращал ключи объекта `data` в верхнем регистре (`LEAD`, `CONTACT`, `COMPANY`), в отличие от остального API в camelCase.

**Стало**

Ключи приходят в camelCase (`lead`, `contact`, `company`); значения (массивы идентификаторов) не меняются.

### FIX-0623-3: поле files эпика Scrum массивом идентификаторов

**Было**

[GET /v1/scrum/epics/:id](/docs/scrum) отдавал поле `files` сырым UF-объектом Битрикс24 (с `VALUE_RAW`, `USER_TYPE_ID` и прочими внутренними метаданными).

**Стало**

`files` — массив идентификаторов вложений (`[417]`) или пустой массив, в едином стиле с остальным API.

### BC-0623-4: создание ключа авторизации только для администраторов

> Поддержка старого формата до: не предусмотрена, ограничение действует сразу

**Было**

Создать ключ авторизации ([POST /v1/keys](/docs/keys-auth)) мог любой пользователь портала.

**Стало**

Создание ключа доступно только администраторам портала, остальным запрос отклоняется.

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

Создавайте ключи под учётной записью с правами администратора Битрикс24.

### FIX-0623-5: заголовок Retry-After при ограничении частоты

**Было**

При ответе `429` (превышение лимита частоты) заголовок `Retry-After` не возвращался, и интегратор не знал, через сколько повторить запрос.

**Стало**

Ответ `429` несёт `Retry-After` с интервалом в секундах. Используйте его как паузу перед повтором.

### FIX-0623-6: удалённый сервер снова отдаёт 404

**Было**

[GET /v1/infra/servers/:id](/docs/infra/servers/get) для мягко удалённого сервера возвращал `200` с полным телом и `status: "deleted"`, хотя документация обещает `404`. Клиент, опрашивающий эндпоинт и ожидающий `404` как подтверждение удаления, его не получал.

**Стало**

Эндпоинт возвращает `404 NOT_FOUND` для удалённого сервера — так же, как [список](/docs/infra/servers/list) и [удаление](/docs/infra/servers/delete), и как описано в документации.

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

Если ваш код полагался на `200` с `status: "deleted"`, переключитесь на проверку `404` (либо на отсутствие сервера в [списке](/docs/infra/servers/list)) как на признак удаления.

### NEW-0623-7: Универсальные списки — полный REST API

Появился раздел [Списки](/docs/lists) (scope `lists`): программное управление универсальными списками Битрикс24 — самими списками, их полями, разделами и элементами. Это 24 эндпоинта под `/v1/lists` поверх методов `lists.*`.

Список адресуется типом инфоблока (`iblockTypeId` — `lists`, `lists_socnet` или `bitrix_processes`, по умолчанию `lists`) и идентификатором: числовой сегмент пути трактуется как `IBLOCK_ID`, строковый — как символьный `IBLOCK_CODE`. Поля, разделы и элементы доступны вложенными путями.

Если модуль «Универсальные списки» не подключён на портале, вызов возвращает `409 LISTS_MODULE_NOT_ENABLED` — это признак выключенного модуля, а не ошибка интеграции.

**Затронутые эндпоинты:** `/v1/lists`, `/v1/lists/:iblockId`, `/v1/lists/:iblockId/fields`, `/v1/lists/:iblockId/sections`, `/v1/lists/:iblockId/elements`

### FIX-0623-8: флаг isChildrenListEnabled у связей смарт-процессов

**Было**

Вложенный флаг связи `isChildrenListEnabled` принимался только как `true`/`false`. Значение `Y`/`N`, как у остальных флагов смарт-процесса, молча сохранялось как выключенное.

**Стало**

[POST /v1/smart-processes](/docs/entities/smart-processes/create) и [PATCH /v1/smart-processes/:entityTypeId](/docs/entities/smart-processes/update) приводят `Y`/`N` (а также `1`/`0`, `yes`/`no`) к `true`/`false` для `isChildrenListEnabled` в связях.

### FIX-0623-9: фильтр и выбор пользовательских полей сделок

**Было**

При фильтрации и выборе пользовательских (UF) полей сделки в форме `UF_CRM_*` поле отклонялось с `UNKNOWN_FILTER_FIELD` в фильтре и молча пропускалось из `select`.

**Стало**

Пользовательские поля сделок указываются в camelCase (`ufCrmCheckOut`) и работают без изменений в фильтре и выборе.

**Затронутые эндпоинты:** [GET /v1/deals](/docs/entities/deals/list), [POST /v1/deals/search](/docs/entities/deals/search)