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

← Журнал изменений · Июнь 2026

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

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

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

Было

GET /v1/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 отдавал поле files сырым UF-объектом Битрикс24 (с VALUE_RAW, USER_TYPE_ID и прочими внутренними метаданными).

Стало

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

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

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

Было

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

Стало

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

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

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

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

Было

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

Стало

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

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

Было

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

Стало

Эндпоинт возвращает 404 NOT_FOUND для удалённого сервера — так же, как список и удаление, и как описано в документации.

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

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

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

Появился раздел Списки (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 и PATCH /v1/smart-processes/:entityTypeId приводят Y/N (а также 1/0, yes/no) к true/false для isChildrenListEnabled в связях.

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

Было

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

Стало

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

Затронутые эндпоинты: GET /v1/deals, POST /v1/deals/search