Изменения API: 15 октября 2026

← Журнал изменений · Октябрь 2026

FIX-1015-1: Точный счётчик при поиске по временным окнам

Было

При поиске с meta.autoWindowed: true поле meta.total могло содержать только число строк, собранных до ранней остановки по limit, вместо количества всех совпадений.

Стало

Если точное количество неизвестно из-за неполного обхода временных окон, ключ meta.total отсутствует. Полный успешный результат сохраняет точный счётчик после удаления повторов, включая 0 для пустой выдачи. Дополнительные запросы только ради счётчика не выполняются. Поиск с autoWindow: false сохраняет прежнее поведение.

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

Проверяйте наличие meta.total перед использованием. Количество возвращённых записей — data.length; наличие следующих результатов определяет meta.hasMore.

NEW-1015-2: Восстановление базы приложения

POST /v1/infra/servers/:id/db/restore принимает восстановление SQLite из готовой копии, в том числе из удалённого приложения своего портала. Перед заменой создаётся защитная копия; остановленное приложение остаётся остановленным. Ответ — 202 QUEUED, статус доступен в restore списка копий. Ключ только для чтения не может запустить восстановление. Инструкция.

BC-1015-3: запись сущностей отклоняет вложенный объект fields

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

Было

При создании или обновлении сущности тело с объектом fields могло получить успешный ответ, хотя вложенные поля не сохранялись.

Стало

Передавайте поля сущности в корне JSON. Объект fields на путях записи с внутренней обёрткой отклоняется до вызова Битрикс24 с 400 NESTED_FIELDS_ENVELOPE. Для пакетной записи ошибка указана в результате элемента или вызова. Объявленное поле fields, например у документов, сохраняет прежнее поведение.

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

Уберите внешнюю обёртку fields из тел создания, обновления, импорта и пакетной записи сущностей. Проверьте, что имена полей находятся в корне каждого объекта записи.

BC-1015-4: имя контакта длиннее 50 знаков отклоняется до записи

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

Было

Поле name при создании и изменении контакта принимало более 50 знаков. Битрикс24 сохранял только первые 50, а ответ сообщал об успешной записи.

Стало

Для name установлен предел 50 кодовых точек Unicode. Одиночные POST /v1/contacts и PATCH /v1/contacts/{id} отклоняют более длинное значение с 400 INVALID_PARAMS до записи. Пакет сущности POST /v1/contacts/batch возвращает 400 BATCH_ITEM_VALIDATION, импорт POST /v1/contacts/import — 400 IMPORT_ITEM_VALIDATION; оба проверяют весь ввод до записи. В POST /v1/batch недопустимый вызов получает INVALID_PARAMS в data.errors, остальные допустимые вызовы могут выполняться. Предел объявлен в OpenAPI, GET /v1/contacts/fields и GET /v1/guide. Остальные поля контакта этим пределом не ограничены.

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

Перед отправкой проверяйте длину name. Если она превышает 50 знаков, попросите пользователя сократить имя и отправить его снова. Не обрезайте имя без согласия пользователя.

FIX-1015-5: Обновление события на весь день сохраняет этот признак

Было

PATCH /v1/calendar-events/:id без skipTime мог снять признак события на весь день и обнулить длительность.

Стало

При обновлении других полей skipTime и даты события на весь день сохраняются. Явный skipTime: false по-прежнему снимает признак.

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

Повторять skipTime: true в каждом обновлении больше не требуется.

FIX-1015-6: методы Follow-up звонков доступны на всех порталах

Было

Методы POST /v1/calls/followups/list и GET /v1/calls/followups/:callId были помечены как находящиеся в процессе раскатки с обновлением Битрикс24 call 26.600.0: в документации стояла заметка о раскатке, а на портале без обновления платформа отвечала 422 METHOD_NOT_YET_AVAILABLE с полем error.release.

Стало

Обновление call 26.600.0 есть на всех порталах, пометка о раскатке снята из документации и спецификации openapi.json. Код METHOD_NOT_YET_AVAILABLE для этих методов больше не возвращается; ответ HTTP 200 у работающих вызовов не меняется. Менять в интеграции ничего не нужно.

BC-1015-7: Признак экстранет-группы доступен только для чтения

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

Было

POST /v1/workgroups и PATCH /v1/workgroups/{id} принимали isExtranet и сырой IS_EXTRANET с успешным ответом, хотя Битрикс24 определяет признак по привязке группы к сайтам, а прямое значение не сохраняет.

Стало

Прямая передача признака, включая false и true, отклоняется до записи: одиночные операции возвращают 400 READONLY_FIELD; POST /v1/workgroups/batch с action:create|update — 400 BATCH_ITEM_VALIDATION. В POST /v1/batch ошибки отдельных операций имеют код READONLY_FIELD: все отклонены — HTTP 400, смешанный результат — HTTP 200 с ошибками отклонённых операций. Поле публикуется как доступное только для чтения; фактическое значение по-прежнему возвращается при чтении группы. Запись siteId и SITE_ID остаётся запрещённой.

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

Уберите isExtranet и его сырые варианты из тел создания и изменения, включая элементы пакетов. Передавайте только изменяемые поля. Если нужен выбор вида группы, используйте возможности Битрикс24: прямое назначение этого признака через API Вайбкод его не выполняет.

NEW-1015-8: Запись в базу приложения через API и MCP

POST /v1/infra/servers/:id/db/execute выполняет до 64 SQL-выражений одной транзакцией. POST/PATCH/DELETE /v1/infra/servers/:id/db/tables/:table/rows[/:key] правят отдельные строки; чтение возвращает rowKeys и признак редактируемости в схеме. Перед записью готовится защитная копия: пока её нет, ответ 409 APP_DB_BACKUP_NOT_READY с идентификатором копии и Retry-After. Ключ только для чтения не может записывать. Запись с неизвестным исходом автоматически не повторяется. MCP manage_app_db получил action: execute с повтором только на время подготовки копии. Инструкция.

NEW-1015-9: Число просмотров сообщения по запросу

GET /v1/chats/messages/{messageId}/viewers принимает необязательный параметр includeViewedCount со значением Y или N. Значение передаётся в Битрикс24 без изменения. При Y ответ может содержать viewedCount — общее число просмотров сообщения, независимо от размера страницы читателей. Запрос без параметра сохраняет прежнее поведение.

BC-1015-10: Демо Коворк/Код включается по согласию сотрудника

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

Было

Вход в приложение или создание ключа автоматически активировали демо при выполнении условий акции.

Стало

Вход в приложение и создание ключа больше не активируют демо автоматически. Уже выданные демо сохраняются.

GET /v1/cowork/me и GET /v1/cowork/state возвращают demoOffer с тарифом, длительностью, ссылкой на правила и shouldPrompt. При отказе приглашение больше не показывается, место акции остаётся свободным.

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

Клиенту нужно предложить выбор и вызвать POST /v1/cowork/demo с action: accept, предложенными tier и durationDays либо с action: decline. Требуется ключ десктопа с vibe:cowork. Ошибка 409 COWORK_DEMO_UNAVAILABLE означает, что нужно обновить состояние и предложение. При reason: terms_changed ответ содержит свежее error.details.demoOffer (tier, durationDays, rulesUrl, shouldPrompt); покажите его и запросите согласие заново. При остальных причинах details отсутствует. Повтор принятия не продлевает демо.

FIX-1015-11: погашение купона больше не отказывает порталам сотрудников платформы

Было

POST /v1/cowork/coupon/redeem отказывал кодом COUPON_SELF_PORTAL (HTTP 409), если за порталом стоит сотрудник платформы с правом выдавать купоны — сам гасящий либо участник портала, владелец API-ключа или владелец сервера на нём. Купон при этом оставался целым.

Стало

Этот отказ снят: купон гасится на любом портале по общим правилам, и код COUPON_SELF_PORTAL больше не возвращается. Успешное погашение по-прежнему отвечает HTTP 200 с тем же телом; строка кода убрана из таблицы ответов метода в документации. Менять в интеграции ничего не нужно.

FIX-1015-12: деплой приложения на Docker Compose больше не падает на собственном контейнере

Было

POST /v1/infra/servers/:id/deploy отдельного сервера, на котором команда start поднимает приложение через docker compose up, завершался ошибкой DEPLOY_FAILED на шаге healthcheck, если Compose не пересоздавал контейнер. Порт продолжал держать прежний процесс docker-proxy, и проверка порта принимала его за постороннего держателя — и при "hardening": "off", и после автоматического отката изоляции.

Стало

Шаг stop_existing останавливает командой docker stop запущенный контейнер Docker Compose самого приложения, если он публикует порт приложения, а папка проекта в метке com.docker.compose.project.working_dir совпадает с extractTo или лежит внутри него. Команда start поднимает контейнер заново, и деплой проходит проверку порта. Шаг stop_existing называет остановленный контейнер в stdout. Другие посторонние процессы и контейнеры других проектов по-прежнему не завершаются.

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

Действий не требуется. Команда start должна поднимать контейнер приложения: если она этого не делает, деплой завершится ошибкой на шаге healthcheck, потому что порт останется свободным.

FIX-1015-13: Сборка сообщает о неисправном хосте

При вызове POST /v1/infra/servers/:id/deploy для приложения галактики отсутствие Docker на хосте теперь возвращает 502 GALAXY_HOST_UNHEALTHY с retryable: false до запуска сборки вместо GALAXY_APP_BUILD_FAILED. Обратитесь в поддержку для восстановления хоста и только затем повторите выкладку. Не удаляйте приложение: пересоздание приложения не исправляет хост.