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

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

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

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

Было

GET /v1/posts/comments возвращал файловые метаданные вместе с любыми дополнительными полями ответа Битрикс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, POST /v1/pages/:id/restore, POST /v1/pages/:id/copy и POST /v1/pages/:id/move. Действия возвращают перечитанную страницу. Перенос требует явного назначения, а копирование активной страницы может сразу опубликовать копию по правилам Битрикс24.

POST /v1/pages/from-template создаёт страницу по коду из GET /v1/page-templates. GET /v1/pages/:id/public-url, GET /v1/pages/:id/preview, GET /v1/pages/:id/settings и GET /v1/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 принимал запрос: хост возвращался в 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, а не к повтору запуска.

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

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

Было

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

Стало

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

• POST /v1/keys и PATCH /v1/keys/{id} — поле name, ответ 400 VALIDATION_ERROR;
• POST /v1/ai/credentials и PATCH /v1/ai/credentials/:id — поле 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 отдаёт коды блоков, доступные на портале. Каталог общий для портала и не разбит на страницы: сузить выборку можно параметром section.
• Блоки страницы — GET /v1/pages/{pageId}/blocks. По умолчанию читается ЧЕРНОВИК страницы, а не опубликованная версия: именно черновиковые идентификаторы принимают все записи. Прочитать опубликованное можно параметром version=published, а содержимое блоков приходит только по явному запросу content=true. Ответ называет версию, которую вернул, — и в общем блоке, и у каждого блока отдельно.
• Добавить и изменить — POST /v1/pages/{pageId}/blocks ставит блок из каталога, PATCH /v1/pages/{pageId}/blocks/{blockId} заменяет его разметку целиком. Обе записи идут в черновик, и ответ говорит об этом прямо: посетители увидят изменения после публикации страницы.
• Удаление обратимо — DELETE /v1/pages/{pageId}/blocks/{blockId} переносит блок в корзину страницы, а POST /v1/pages/{pageId}/blocks/{blockId}/restore возвращает его обратно; адрес возврата приходит прямо в ответе на удаление. Безвозвратного удаления в 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 в спецификации и в справочнике 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 приезжает 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, PATCH /v1/items/:entityTypeId/userfields/:id и DELETE /v1/items/:entityTypeId/userfields/:id, как и короткие адреса счетов /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 запрос Galaxy с полной UTF-8-строкой KEY=VALUE\n длиннее 65536 байт получает 400 GALAXY_DEPLOY_INVALID_ENV. Те же env-ограничения применяются при создании через POST /v1/infra/servers. Значения с \r, \n, NUL или некорректными Unicode-суррогатами получают 400 VALIDATION_ERROR на deploy и 400 INVALID_REQUEST на create.

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

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

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

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

Было

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

Стало

Успешный ответ 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 со сменой 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-строку, если она содержит секрет.