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

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

### BC-1006-1: Файлы комментариев возвращают только текущие метаданные

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

**Было**

[GET /v1/posts/comments](/docs/posts/comments/read) возвращал файловые метаданные вместе с любыми дополнительными полями ответа Битрикс24.

**Стало**

В `files` сохраняются `id`, `date`, `type`, `name`, `size`, `image`, `authorId`, `authorName`, `urlPreview`, `urlShow`, `urlDownload`. В `image` сохраняются только `width` и `height`. Неизвестные поля и значения неверного типа исключаются. Ссылки с учётными данными по-прежнему скрываются.

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

Используйте только перечисленные поля и ожидайте указанные примитивные типы; удалите чтение дополнительных полей и вложенных объектов. Текущие файловые метаданные и форма массива или словаря сохраняются. Поддержка сквозного проброса дополнительных полей не предусмотрена: закрытый DTO применяется сразу.

### NEW-1006-2: действия и данные сайта

Добавлены `POST /v1/sites/:id/publication`, `POST /v1/sites/:id/unpublish`, `POST /v1/sites/:id/trash` и `POST /v1/sites/:id/restore` с перечитанным состоянием сайта. Чтение: `GET /v1/sites/:id/public-url`, `GET /v1/sites/:id/preview`, `GET /v1/sites/:id/settings`, `GET /v1/sites/:id/export`, `GET /v1/sites/:id/my-permissions`. Экспорт ограничен 8 МиБ; превышение возвращает `413 SITE_EXPORT_TOO_LARGE`. `PUT /v1/sites/:id/permissions` полностью заменяет права непустым словарём; `DELETE /v1/sites/:id/permissions` явно очищает их. `my-permissions` показывает операции текущего пользователя, не назначенные роли. Все операции требуют скоуп `landing` и поддерживают `scope`.

### NEW-1006-3: Действия страниц и справочник шаблонов

Добавлены действия страниц сайтов: [POST /v1/pages/:id/trash](/docs/entities/pages/trash), [POST /v1/pages/:id/restore](/docs/entities/pages/restore), [POST /v1/pages/:id/copy](/docs/entities/pages/copy) и [POST /v1/pages/:id/move](/docs/entities/pages/move). Действия возвращают перечитанную страницу. Перенос требует явного назначения, а копирование активной страницы может сразу опубликовать копию по правилам Битрикс24.

[POST /v1/pages/from-template](/docs/entities/pages/from-template) создаёт страницу по коду из [GET /v1/page-templates](/docs/entities/page-templates). [GET /v1/pages/:id/public-url](/docs/entities/pages/public-url), [GET /v1/pages/:id/preview](/docs/entities/pages/preview), [GET /v1/pages/:id/settings](/docs/entities/pages/settings) и [GET /v1/pages/resolve](/docs/entities/pages/resolve) получают адреса, настройки и идентификатор страницы по публичному пути. Всем маршрутам нужен scope `landing`, для баз знаний и групп доступен query-параметр `scope`.

### NEW-1006-4: Папки сайта

Добавлены `GET|POST /v1/sites/:id/folders`, `PATCH /v1/sites/:id/folders/:folderId` и `POST`-действия `trash`, `restore`, `publication`, `unpublish`. Нужен скоуп `landing`; для нестандартного типа сайта передайте `scope`. Ответ записи содержит перечитанную папку. Частичный PATCH сохраняет родителя; `parentId: null` переносит папку в корень. Публикация и снятие затрагивают цепочку родителей; корзина снимает с публикации страницы папки и вложенных папок, восстановление не публикует их обратно.

### BC-1006-5: хост-галактика без агента получает код AGENT_NEVER_CONNECTED

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

**Было**

Если на хосте-галактике (`kind: "GALAXY"`) не поднялся агент, платформа переводила хост в `error` с причиной текстом в `provisionError`, но `provisionErrorCode` оставался `null`. Различить этот случай по коду было нельзя, а [`POST /v1/infra/servers/:id/start`](/docs/infra/lifecycle/start) принимал запрос: хост возвращался в `running`, начисление возобновлялось, а агента по-прежнему не было.

**Стало**

Новый переход хоста в это состояние получает `provisionErrorCode: "AGENT_NEVER_CONNECTED"` — тот же код, что и отдельный сервер. Уже существующие `ERROR`-строки с прежним текстом причины сохраняют `provisionErrorCode: null`; `/start` и `availableActions` распознают их по точному legacy-тексту и дают тот же путь восстановления. `POST /start` на таком хосте отвечает `422` с кодом, в `error.availableActions` приходят `repair` и `delete`.

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

Если вы перезапускаете хосты-галактики в `error` по расписанию, обрабатывайте `AGENT_NEVER_CONNECTED` либо точную legacy-причину `Galaxy host booted but its agent never connected — the on-boot Docker/agent install failed. Delete and recreate the host, or repair it.` как сигнал к [`POST /v1/infra/servers/:id/repair`](/docs/infra/lifecycle/repair), а не к повтору запуска.

### BC-1006-6: имя ключа и AI-подключения из одних пробелов отклоняется

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

**Было**

Значение, состоящее только из пробелов, табуляций или переводов строки (например `"   "`), проходило проверку «не короче одного символа». Ключ и AI-подключение принимались с таким именем и сохранялись без единого видимого символа.

**Стало**

Такое значение отклоняется до записи:

- [POST /v1/keys](/docs/management-keys) и [PATCH /v1/keys/{id}](/docs/management-keys) — поле `name`, ответ `400 VALIDATION_ERROR`;
- [POST /v1/ai/credentials](/docs/ai/credentials/create) и [PATCH /v1/ai/credentials/:id](/docs/ai/credentials/update) — поле `name`, ответ `400 INVALID_REQUEST`.

На путях записи названия приложения и заголовка встройки (`title`, `catalogTitle`) этот же запрет действует с 16.09 — запись **BC-0916-20**; здесь он не менялся.

Принятое имя, как и прежде, сохраняется ровно таким, как прислано: пробелы по краям не обрезаются, отклоняется только имя, в котором нет ни одного непробельного символа. Запросы с обычным именем и запросы без поля `name` там, где оно необязательно, работают как прежде.

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

Менять код нужно тем, кто подставлял в `name` строку из одних пробелов, например необрезанный пользовательский ввод: проверяйте, что в имени есть хотя бы один непробельный символ, до отправки запроса.

### FIX-1006-7: `GET /v1/chats/:dialogId/messages`: потолок `limit` действует для любого регистра имени

**Было**

Параметр `LIMIT` (и `Limit`) без lowercase `limit` уходил в Битрикс24 как есть: потолок 200 и пометка `meta.appliedLimit` не применялись.

**Стало**

Любое написание `limit` сводится к одному значению (lowercase приоритетнее), ограничивается 200 и уходит как `LIMIT`; при ограничении ответ содержит `meta.requestedLimit` и `meta.appliedLimit`. Остальные параметры запроса передаются без изменений.

### NEW-1006-8: Системные страницы и области шаблона

API Вайбкод позволяет читать и назначать системные страницы через `/v1/sites/:id/system-pages`, получать URL роли через `/v1/sites/:id/system-pages/:type/url` и явно снимать роли сайта или страницы. `/v1/site-templates` возвращает справочник раскладок. `/v1/sites/:id/template-areas` и `/v1/pages/:id/template-areas` поддерживают GET, PATCH со слиянием и DELETE для полной очистки. Пропущенные области сохраняются, null удаляет одну область. Требуется скоуп landing. Записи проверяют сохранённое состояние; молчаливый отказ Битрикс24 возвращается как 422 BITRIX_ERROR.

### BC-1006-9: подсказка отказа при отсутствующей облачной машине называет только доступные вызывающему адреса

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

**Было**

Сервер без облачной машины отвечал `422 VM_MISSING` на пробуждение `POST /v1/infra/servers/{id}/wake` — в том числе при
автоматическом пробуждении внутри `POST /v1/infra/servers/{id}/deploy`, `/exec`, `/upload`
и `GET /v1/infra/servers/{id}/logs`: у всех четырёх общая преамбула, и будит она одинаково. Подсказка ответа
была одна на всех и советовала два адреса: `DELETE /v1/infra/servers/{id}`, затем
`POST /v1/infra/servers`. Ключу в режиме «только чтение» выкладка разрешена, а оба
советуемых вызова отвечают ему `403 WRITE_BLOCKED_READONLY_KEY`: платформа печатала
инструкцию, исполнение которой сама же запрещала. То же получали ключ без скоупа
`vibe:infra`, участник команды разработки на чужом сервере и владелец, чей аккаунт ждёт
удаления.

**Стало**

Адрес попадает в подсказку, только если он доступен этому вызывающему. Ключ, которому
отказано в сносе или в создании, получает вместо адреса причину отказа и рецепт — что
именно изменить (переключить режим ключа, выдать скоуп `vibe:infra`, позвать владельца
сервера); когда закрыты обе половины разными дверьми, называются обе причины. Доступная
половина рецепта по-прежнему называется адресом.

У галакси-приложения (`kind: GALAXY_APP`) тот же ответ вместо сноса и создания советует
перевыложить код через `POST /v1/infra/servers/{id}/deploy`. Этот адрес теперь тоже называется,
только если выкладка вызывающему открыта. На практике это касается одного случая: участник
команды разработки читает `GET /v1/infra/servers/{id}/logs` своим собственным ключом, а на его
Битрикс24 выключен пилот галактик — вместо адреса он получает причину и рецепт. Владелец
сервера, ключ команды разработки, выданный на этот сервер, и вызывающий по связке с приложением
этот ответ не получают: их запросы к галакси-приложению обслуживаются отдельной веткой.

У такого вызывающего меняются ДВА поля тела: `error.hint` и `error.message` — последнее
больше не говорит «удалите сервер и создайте новый», раз исполнить это ему нечем. Третье
поле, `error.userMessage`, ему больше не приходит вовсе: оно локализовано и безусловно
приказывало снести сервер, то есть противоречило соседней подсказке того же ответа. Прежний
текст всех трёх полей сохранён для ключа с полным доступом, владеющего сервером. Не менялись
ни для кого код (`VM_MISSING`) и статус (`422`).

Ответы `VM_MISSING` маршрутов `POST /v1/infra/servers/{id}/start`, `/stop` и `/reboot`
переведены на ту же подсказку и впервые несут поле `error.hint` — поле дополнительное,
прежние клиенты его игнорируют.

**Затронутые эндпоинты:** `POST /v1/infra/servers/{id}/wake`, `/deploy`, `/exec`, `/upload`,
`/start`, `/stop`, `/reboot` и `GET /v1/infra/servers/{id}/logs`.

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

Клиент, который показывал на `422 VM_MISSING` ТОЛЬКО `error.userMessage`, в случае отказа
останется без текста. Не полагайтесь на наличие `error.userMessage` в этом ответе: читайте
`error.message` и `error.hint` — там и причина отказа, и то, что нужно изменить.

### BC-1006-10: привязку смарт-процесса к рабочему месту больше нельзя менять полем customSectionId

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

**Было**

`PATCH /v1/smart-processes/:id` принимал поле `customSectionId`. До портала значение доходило, но
там отбрасывалось: метод обновления типа не меняет его привязку к цифровому рабочему месту, её
меняют только со стороны рабочего места. Запрос отвечал успехом, и вызывающая сторона считала, что перенесла
смарт-процесс в другое рабочее место, тогда как не менялось ничего. В справочнике
`GET /v1/smart-processes/fields` поле выглядело обычным записываемым.

**Стало**

`customSectionId` больше не принимается при обновлении типа. `PATCH /v1/smart-processes/:id`
с этим полем отвечает `400 READONLY_FIELD` и называет поле; так же отвечают обе пакетные операции
обновления. `POST /v1/smart-processes` поле принимает как раньше. В выдаче
`GET /v1/smart-processes/fields` у поля стоит признак `readonlyOnUpdate`: передать значение можно
только при создании, но после создания оно меняется вместе с привязкой. Название и описание поля
помечают его устаревшим.

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

Уберите `customSectionId` из тела `PATCH /v1/smart-processes/:id` — иначе запрос целиком получит
`400 READONLY_FIELD` вместо прежнего «успеха». Это особенно важно, если код читает запись через
`GET` и отправляет весь объект обратно: такой вызов теперь отклоняется. Менять привязку следует со
стороны рабочего места — `PATCH /v1/automated-solutions/:id` с полным набором `typeIds` (набор
перезаписывается целиком, поэтому передавайте весь список). Признак `readonlyOnUpdate` в ответе
`GET /v1/smart-processes/fields` позволяет отличать такие поля до отправки запроса.

### NEW-1006-11: появилась сущность «Цифровые рабочие места» — /v1/automated-solutions

Открыта сущность `/v1/automated-solutions` с семью операциями: `GET /v1/automated-solutions`,
`GET /v1/automated-solutions/:id`, `POST /v1/automated-solutions`,
`PATCH /v1/automated-solutions/:id`, `DELETE /v1/automated-solutions/:id`,
`GET /v1/automated-solutions/fields`, `POST /v1/automated-solutions/batch`. Требуется право
`crm`. Раньше программного пути создать цифровое рабочее место и привязать к нему
смарт-процессы не существовало.

У записи три поля: `id` (только чтение), `title` (обязательное при создании) и `typeIds` — массив
идентификаторов привязанных типов смарт-процессов: поле `id` типа из `GET /v1/smart-processes`, а не
его `entityTypeId`. Неизвестное значение отбрасывается без ошибки. Привязка выполняется со стороны рабочего места:
на `PATCH` набор `typeIds` перезаписывается целиком, поэтому передавайте полный список либо не
передавайте ключ вовсе.

Фильтрация и сортировка списка доступны только по `id` и `title` — это ограничение метода портала.
Запрос с любым другим полем отбивается до вызова портала (`400 UNKNOWN_FILTER_FIELD` или
`400 UNKNOWN_SORT_FIELD`) вместо тихой отдачи всей коллекции.

Добавлен код ошибки `403 B24_AUTOMATED_SOLUTION_LIMIT_EXCEEDED`: портал исчерпал допустимое число
цифровых рабочих мест, в облаке потолок зависит от тарифа Битрикс24. Повтор запроса не поможет —
нужно освободить место или поднять тариф. Отказ портала удалить непустое рабочее место приходит как
`422` с `b24Code: "HAS_BOUND_TYPES"` и подсказкой о порядке действий: сначала перенесите
привязанные типы, затем повторите удаление.

### NEW-1006-12: блоки лендинга через API: страницу теперь можно наполнить содержимым

Раньше через API можно было создать сайт, создать страницу и опубликовать её — но положить на
страницу хоть один блок было нечем, и программно собранный сайт оставался пустым. Появились
шесть маршрутов, закрывающих весь сценарий.

- **Каталог блоков** — [GET /v1/block-repository](/docs/api-reference) отдаёт коды блоков,
  доступные на портале. Каталог общий для портала и не разбит на страницы: сузить выборку
  можно параметром `section`.
- **Блоки страницы** — [GET /v1/pages/{pageId}/blocks](/docs/api-reference). По умолчанию
  читается ЧЕРНОВИК страницы, а не опубликованная версия: именно черновиковые идентификаторы
  принимают все записи. Прочитать опубликованное можно параметром `version=published`, а
  содержимое блоков приходит только по явному запросу `content=true`. Ответ называет версию,
  которую вернул, — и в общем блоке, и у каждого блока отдельно.
- **Добавить и изменить** — [POST /v1/pages/{pageId}/blocks](/docs/api-reference) ставит блок
  из каталога, [PATCH /v1/pages/{pageId}/blocks/{blockId}](/docs/api-reference) заменяет его
  разметку целиком. Обе записи идут в черновик, и ответ говорит об этом прямо: посетители
  увидят изменения после публикации страницы.
- **Удаление обратимо** — [DELETE /v1/pages/{pageId}/blocks/{blockId}](/docs/api-reference)
  переносит блок в корзину страницы, а
  [POST /v1/pages/{pageId}/blocks/{blockId}/restore](/docs/api-reference) возвращает его
  обратно; адрес возврата приходит прямо в ответе на удаление. Безвозвратного удаления в API
  нет намеренно, поэтому ошибку всегда можно отменить. Блок из корзины виден по
  `deleted=true`.

Запись по идентификатору, которого нет в черновике страницы, отклоняется ДО обращения к
Битрикс24 — ответ 404 с кодом `BLOCK_NOT_IN_DRAFT`. Это сделано ради определённости: иначе
такая запись могла бы завершиться успехом, ничего не изменив.

Булевы поля тела (`active` у добавления, `designed` у замены разметки) принимают только
`true`/`false` (и строки `"1"`/`"0"`). Любое другое значение — отказ 400 с кодом
`INVALID_ACTIVE` / `INVALID_DESIGNED`, а не молчаливое «нет»: иначе блок создавался бы скрытым,
а ответ был бы 201, и отличить его от заказанного было бы нечем.

`content` на создании тоже проверяется по типу: не-строка — отказ 400 `INVALID_CONTENT`, а не
молчаливое падение на разметку каталога. Поле по-прежнему необязательно.

Всем шести маршрутам нужен скоуп `landing`. Страницам базы знаний, групп и вайбов дополнительно
нужен параметр `scope` — без него Битрикс24 отвечает, что страницы не существует, хотя она есть.

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

### FIX-1006-13: ответ постановки и снятия реакции описан как `data.result`

**Было**

Справочник API обещал, что `POST /v1/chats/messages/:messageId/reactions` и `DELETE /v1/chats/messages/:messageId/reactions/:reaction` отвечают `{ "success": true, "data": true }`. Для `GET /v1/chats/:dialogId/pins/count` отказ `422 BITRIX_ERROR` описан не был.

**Стало**

Справочник описывает фактический ответ обоих методов реакций: `{ "success": true, "data": { "result": true } }`. Признак успеха читайте из `data.result`. Для `GET /v1/chats/:dialogId/pins/count` описан отказ `422 BITRIX_ERROR` с `error.b24Code` `CHAT_NOT_FOUND`, когда чата нет. Сами методы не менялись, успешный ответ HTTP 200 остаётся прежним.

### NEW-1006-14: Поиск, синхронизация и сохранение файлов Диска

API Вайбкод позволяет искать доступные пользователю файлы по всему Диску через `POST /v1/disk/search`.
`GET /v1/disk/capabilities` сообщает, какие возможности поддерживает подключённый Битрикс24.
Поиск и сохранение файлов доступны независимо от поддержки синхронизации.

Методы `/v1/disk/sync/*` позволяют получать снимок метаданных, продолжать прерванную синхронизацию
и читать последующие изменения. `POST /v1/disk/sync/check` проверяет актуальное состояние объектов
и доступ пользователя к ним.

`POST /v1/disk/uploads/reserve` и `POST /v1/disk/uploads` позволяют создать файл или сохранить новую
версию существующего файла. `GET /v1/disk/uploads/:operationId` возвращает состояние операции.
Если результат записи неизвестен, клиент проверяет её состояние перед повторной отправкой.
Проверка версии файла не гарантирует защиту от одновременного изменения другим пользователем.

### FIX-1006-15: пример ответа индикатора «печатает» приведён к фактическому

**Было**

Пример ответа [POST /v1/chats/:dialogId/typing](/docs/chats/messages/typing) в спецификации и в справочнике API показывал `data: true`.

**Стало**

Пример показывает фактический ответ: `data` — объект с полем `result`, `{ "success": true, "data": { "result": true } }`. Сам ответ не менялся, он и раньше приходил в такой форме.

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

Если код проверял `data === true` по прежнему примеру, проверяйте `data.result`.

### BC-1006-16: вложения обращений принимают документы, а не только изображения

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

К обращению теперь можно приложить текст, таблицу, сохранённую веб-страницу и архив — раньше приём пропускал только изображения.

Тип файла определяется по РАСШИРЕНИЮ имени, а не по заголовку `Content-Type` части: браузеры про эти форматы сообщают неверно — у `.md` тип пустой, у `.zip` на Windows приезжает `application/x-zip-compressed`, у `.csv` с установленным офисным пакетом — тип таблицы. Принимаются `txt`, `md`, `csv`, `html`, `htm`, `xlsx`, `zip` рядом с прежними `png`, `jpg`, `jpeg`, `webp`, `gif`. Лимиты не менялись: 10 МБ на файл, 5 файлов в сообщении, 25 в обращении.

Изображение по-прежнему перекодируется платформой и показывается миниатюрой. Документ сохраняется побайтово и всегда отдаётся на скачивание, поэтому миниатюры у него нет: в ответе [POST /v1/feedback/attachments](/docs/feedback) приезжает `kind: "DOCUMENT"`, `thumbnailUrl: null`, а `width` и `height` равны нулю. Адрес миниатюры документа отвечает `404`. У изображения `kind` равен `IMAGE`.

Поле `kind` добавлено и в списки вложений всех операций чтения обращения, а список допустимых расширений приехал в `attachmentAllowedExtensions` в `GET /v1/me`. Соседнее `attachmentAllowedMime` там же расширилось: кроме четырёх типов изображений в нём теперь `text/plain`, `text/markdown`, `text/csv`, `text/html`, `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` и `application/zip`. Это справочный список типов, а не правило приёма: решает расширение имени, и по заявленному типу при нераспознанном имени принимаются только изображения.

Отказы приёма: имя не распознано (расширения нет или оно вне списка) и `Content-Type` не из четырёх типов изображений — `400 INVALID_MIME`, содержимое не совпало с расширением (архив без сигнатуры) — `400 MIME_MISMATCH`, пустой файл — `400 INVALID_FILE_EMPTY`.

⚠️ **Приём изображений сузился в двух местах.** Класс вложения теперь определяется расширением имени, и там, где расширение и заявленный тип расходятся, ответ изменился:

**Было**

Класс изображения определялся заявленным `Content-Type`, и расширение имени, расходившееся с ним, не учитывалось.


**Стало**

Решает расширение, и два расходящихся случая отвечают по-разному:

- `photo.zip` с `Content-Type: image/png` и байтами PNG раньше принимался как изображение (`200`, `kind: IMAGE`), теперь отвечает `400 MIME_MISMATCH`;
- `shot.txt` с `Content-Type: image/png` раньше становился изображением с миниатюрой, теперь принимается как документ (`kind: DOCUMENT`) и миниатюры не получает.

Не сузилось: часть, чьё имя не распознано, — без расширения (`blob` — так её называет `FormData.append`) или с расширением вне обоих списков (`report.pdf`), — по-прежнему принимается как изображение, если её `Content-Type` из прежнего списка изображений, а байты действительно изображение. И наоборот, PNG с ПУСТЫМ `Content-Type`, который раньше отбивался, теперь принимается по расширению имени.

**Что делать интеграторам**. Присылайте имя файла с расширением, соответствующим содержимому. Если вы собирали часть вручную и давали ей имя с чужим расширением, полагаясь на `Content-Type`, — поправьте имя: именно эта пара и перестала приниматься.

### BC-1006-17: чтение, правка и удаление поля смарт-процесса проверяют, что поле принадлежит смарт-процессу из пути

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

**Было**

[GET /v1/items/:entityTypeId/userfields/:id](/docs/userfields/smart-processes/get), [PATCH /v1/items/:entityTypeId/userfields/:id](/docs/userfields/smart-processes/update) и [DELETE /v1/items/:entityTypeId/userfields/:id](/docs/userfields/smart-processes/delete), как и короткие адреса счетов `/v1/userfields/invoices/:id`, находили поле только по идентификатору и не сверяли его с `:entityTypeId`. Запрос по пути счёта с идентификатором поля сделки читал это поле и отвечал `200`. Поле, которого уже нет, отвечало `422 BITRIX_ERROR` с сообщением об отказе по правам, в том числе на повторный `DELETE`.

**Стало**

Перед чтением, правкой и удалением платформа проверяет, что у смарт-процесса из пути есть поле с этим идентификатором. Поле другой сущности и удалённое поле дают одинаковый ответ: `404 NOT_FOUND` у `GET`, `404 ENTITY_NOT_FOUND` у `PATCH` и `DELETE`. Правка и удаление при этом на портал не уходят. `422 BITRIX_ERROR` остаётся для случая, когда поле удалили между проверкой и самим запросом.

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

Ветку «поля нет» переведите с `422 BITRIX_ERROR` на `404`: `NOT_FOUND` у чтения, `ENTITY_NOT_FOUND` у правки и удаления. Повторный `DELETE`, получивший `404`, означает «поле уже удалено». Если интеграция обращалась к полю через путь чужой сущности, возьмите путь той сущности, которой поле принадлежит: для поля сделки — `/v1/userfields/deals/:id`. Каждая из трёх операций стала на один запрос к порталу дольше.

### FIX-1006-18: спецификация редактора бизнес-процессов называет недоступность раздела

**Было**

Спецификация OpenAPI описывала методы `/v1/workflow-designer` как доступный контракт и не называла код `DESIGNER_NOT_RELEASED`. `GET /v1/workflow-designer/capabilities` не называл эту причину.

**Стало**

Ответ по-прежнему `200` у `GET /v1/workflow-designer/capabilities`: пока раздел не открыт для этого ключа, `available` равно false, а `reason` равен `DESIGNER_NOT_RELEASED`. Остальные методы раздела по-прежнему отвечают `403 DESIGNER_NOT_RELEASED` и не обращаются к Битрикс24. Спецификация теперь называет то же самое. Когда раздел для ключа открыт, методы отвечают по существу, и этот код не возвращается.

### NEW-1006-19: Продолжение поиска и список статей заметок

`GET` и `POST /v1/note/documents/search` принимают необязательный `offset` от 0 до 10000 для перехода к следующей странице результатов. Пока `meta.hasMore` равен `true`, увеличивайте `offset` на `limit`; если следующий `offset` превышает 10000, используйте список для полного обхода. Новый `GET /v1/note/documents` возвращает плоский список статей и `meta.nextCursor`. Передавайте этот курсор как URL-кодированный JSON в query-параметре `afterCursor` следующего запроса, пока он не станет `null`, в том числе после пустой страницы. Оглавление базы знаний остаётся деревом, не страницей списка.

### FIX-1006-20: Отсутствующий товар оплаты возвращает 404 независимо от языка портала

**Было**

При добавлении несуществующей строки товара через `POST /v1/crm-payments/{id}/products` некоторые языки портала приводили к `422 BITRIX_ERROR` вместо `404 ENTITY_NOT_FOUND`.

**Стало**

Если портал подтверждает отсутствие строки товара, API возвращает `404 ENTITY_NOT_FOUND` независимо от языка сообщения. Если проверить строку невозможно, сохраняется исходная ошибка добавления.

### BC-1006-21: Деплой Galaxy-приложений проверяет размер строки env

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

**Было**

Деплой Galaxy-приложения принимал `env` без ограничения длины полной строки переменной.

**Стало**

На [POST /v1/infra/servers/:id/deploy](/docs/infra/deploy/deploy) запрос Galaxy с полной UTF-8-строкой `KEY=VALUE\n` длиннее 65536 байт получает `400 GALAXY_DEPLOY_INVALID_ENV`. Те же env-ограничения применяются при создании через [POST /v1/infra/servers](/docs/infra/servers/create). Значения с `\r`, `\n`, NUL или некорректными Unicode-суррогатами получают `400 VALIDATION_ERROR` на deploy и `400 INVALID_REQUEST` на create.

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

До отправки запроса проверять размер каждой Galaxy env-строки в UTF-8, включая имя ключа, `=` и завершающий перевод строки; не отправлять запрещённые символы.

### BC-1006-22: ответ чтения комментариев постов содержит только корректные идентификаторы и поля файлов

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

**Было**

[GET /v1/posts/comments](/docs/posts/comments/read) мог возвращать дробные идентификаторы комментариев и вложений. Схема ответа не перечисляла доступные поля файлов.

**Стало**

Успешный ответ HTTP 200 сохранён. Идентификаторы комментариев и вложений возвращаются только как целые числа, а файлы содержат только документированные необязательные поля. `data.files` по-прежнему может быть массивом или словарём с числовыми ID в качестве ключей.

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

Это изменение сужает ранее опубликованный native-ответ `data.files`: поля вне перечисленного allow-list больше не возвращаются. Интеграциям, которые использовали такие недокументированные поля, нужно перейти на документированные поля (`id`, `date`, `type`, `name`, `size`, `image`, `authorId`, `authorName`, `urlPreview`, `urlShow`, `urlDownload`); для сохранения старого набора полей отдельного совместимого режима нет. Некорректные идентификаторы по-прежнему удаляются из ответа.

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

Проверьте обработку `data.files` и замените чтение недокументированных полей на перечисленный allow-list; неподдерживаемые поля нужно считать отсутствующими.

### NEW-1006-23: Копирование, перенос, порядок и удаление блоков страницы

Добавлены POST-действия copy, move, up, down, show, hide, purge под `/v1/pages/:pageId/blocks/:blockId/` и bulk-purge под `/v1/pages/:pageId/blocks/`. Требуется landing. Блоки проверяются на принадлежность странице до записи. Порядок и видимость перечитываются. purge и bulk-purge необратимо удаляют блоки с файлами; bulk-purge требует непустой blockIds, максимум 50 блоков и 50 изображений. Уцелевшие блоки дают 422 BITRIX_NO_EFFECT со списком error.blockIds. Граница порядка даёт 409 BLOCK_WRONG_SORT.

### FIX-1006-24: переименование сервера обновляет подпись встройки приложения

**Было**

[PATCH /v1/infra/servers/:id](/docs/infra/servers/update) со сменой `displayName` переносил имя в приложение сервера, но подпись его встройки в Битрикс24 — вкладки в карточке CRM или пункта левого меню — оставалась прежней.

**Стало**

Если у приложения сервера есть встройки, при смене `displayName` платформа сначала перепривязывает их с новым названием и только потом сохраняет имя. Когда Битрикс24 не подтвердил привязку, имя не меняется ни у сервера, ни у приложения, и вызов можно повторить: `502 BITRIX_PARTIAL_REBIND` с кодами встроек в `error.unbound` / `error.restored`, `400 NO_USER_TOKEN` без авторизации приложения в Битрикс24, `400 BOX_NO_DEVELOPER_KEY` / `APP_NOT_INSTALLED_ON_BOX` на коробке, `409 APPLICATION_OP_IN_PROGRESS`, пока с приложением идёт другая операция. Ключ, которому запись в данные Битрикс24 закрыта, получает `403 WRITE_BLOCKED_READONLY_KEY` по тем же условиям, что и при переименовании приложения через `PATCH /v1/apps/:id`. Переименование сервера без приложения или приложения без встроек и правка одного описания работают как раньше, ответ остаётся HTTP 200.

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

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

### NEW-1006-25: Чтение блоков страницы и образцов каталога

Добавлены `GET /v1/pages/:pageId/blocks/:blockId`, `GET /v1/pages/:pageId/blocks/:blockId/content`, `GET /v1/block-repository/:code/content` и `GET /v1/block-repository/:code/manifest`. Требуется scope `landing`; READONLY-ключ может читать. Необязательный query `scope=KNOWLEDGE|GROUP|MAINPAGE` выбирает контекст страницы.

Чтение включает черновики. Блок другой страницы, отсутствующий образец или манифест отвечают `404 ENTITY_NOT_FOUND`. Код блока в пути нужно URL-encode. У блоков приложений `repo_N` манифест-файла нет. Ключи `nodes` и `cards` манифеста задают селекторы. Содержимое возвращает HTML и узкий набор данных без полного манифеста; `php: true` означает блок с кодом и ограниченной правкой содержимого. Даты блока — ISO wall clock без выдуманного часового пояса. Строки с credential URL заменяются на `[REDACTED]`, включая всю HTML-строку, если она содержит секрет.