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

[← Журнал изменений](/docs/changelog) · [Октябрь 2026](/docs/changelog/2026-10)

### 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` списка копий. Ключ только для чтения не может запустить восстановление. [Инструкция](/docs/infra/database/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](/docs/calls/followup/list) и [GET /v1/calls/followups/:callId](/docs/calls/followup/get) были помечены как находящиеся в процессе раскатки с обновлением Битрикс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` с повтором только на время подготовки копии. [Инструкция](/docs/infra/database/execute).

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

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

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

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

**Было**

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

**Стало**

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

[GET /v1/cowork/me](/docs/cowork/me) и [GET /v1/cowork/state](/docs/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](/docs/infra/deploy/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`. Обратитесь в поддержку для восстановления хоста и только затем повторите выкладку. Не удаляйте приложение: пересоздание приложения не исправляет хост.