# Изменения API: 12 сентября 2026

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

### BC-0912-1: Назначения сотрудников и отделов для интеграции 1С

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

Администратор портала может назначить аккаунту 1С несколько сотрудников и отделов. Отдел включает все подотделы; персональное назначение имеет приоритет. Существующие персональные связи сохраняются.

**Было**

`POST /v1/onec/tools/{method}/call` использовал персональную связь 1:1.

**Стало**

После включения отделовых назначений вызов учитывает актуальную принадлежность сотрудника. Разные подходящие аккаунты дают 409 `ONEC_MAPPING_CONFLICT`, недоступное назначение — 403 `ONEC_ACCOUNT_UNAVAILABLE`, неподтверждённый справочник — 503 `ONEC_DIRECTORY_UNAVAILABLE`. Изменение версии во время проверки даёт 409 `ONEC_MAPPING_VERSION_CONFLICT`. Операция не переназначается другому аккаунту; результат остаётся доступным только исходному пользователю и ключу.

Выключение функции после первого сохранения не возвращает прежнюю модель: создание операции отвечает 503 `ONEC_ASSIGNMENTS_DISABLED` до повторного включения. Для порталов без перехода сохраняется прежнее поведение.

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

Обрабатывать новые коды отказа `POST /v1/onec/tools/{method}/call`, перечисленные выше.

### NEW-0912-2: Параметр device_id в ссылке подтверждения device-flow

`POST /v1/connect/device/authorize` дописывает `device_id` в ссылку
`verification_uri_complete`, когда присланное в теле запроса значение укладывается в форму
идентификатора: до 128 символов, только латинские буквы, цифры и знаки `. : - _`. Значение
попадает в ссылку как есть, но по правилам URL, поэтому `:` в адресе выглядит как `%3A` —
приёмник декодирует его обратно штатным разбором query-строки.

Значение вне этой формы отбрасывается молча: ручка по-прежнему отвечает `200`, ссылка приходит
без параметра, признака отказа в ответе нет. Так сделано намеренно — поле необязательное, и
отказ ломал бы вход тем, у кого идентификатор съехал.

Нужно для сведения статистики входа: ссылку подтверждения человек нередко открывает не в том
браузере, где начал вход, — копирует её или отдаёт системному браузеру, — и без параметра
внутри самой ссылки связать шаги одного входа нечем.

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

### BC-0912-3: бессмысленное тело у правки сообщения, участников чата и поста отклоняется, а не выполняется

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

**Было**

Три ручки мессенджера и ленты принимали тело без нужных данных и отвечали успехом, хотя делали не то, что просил клиент. [PATCH /v1/chats/{dialogId}/messages/{messageId}](/docs/chats/messages/update) без `message` — пустым, из одних пробелов, из одних тегов переноса `[BR]` или с текстом под другим именем поля (`{"text": …}`) — отправлял в Битрикс24 пустой текст и отвечал `200` «Message updated», а Битрикс24 по тексту, пустому по его собственному правилу, в этом методе **удаляет сообщение** (проверено 2026-09-12: после такого вызова сообщение показывается как «Это сообщение было удалено»). Тело запроса при этом уходило на портал целиком, а портал сворачивает имена параметров без учёта регистра и берёт последний ключ: `{"MESSAGE": "текст", "Message": ""}` тоже удалял сообщение (проверено 2026-09-12). [DELETE /v1/chats/{chatId}/users](/docs/chats/members/remove) и [POST /v1/chats/{chatId}/users](/docs/chats/members/add) передавали `userId` и элементы `users` в Битрикс24 как есть, а портал приводит их к числу по правилам PHP: массив `[47]` становится `1`, слово — `0`. Вызов `{"userId": [47]}` отвечал `200` и удалял из чата пользователя с ID 1 — владельца портала, а не 47; при добавлении `{"users": ["abc"]}` отвечал `200` «добавлено», никого не добавив, а вложенный массив ронял портал (проверено 2026-09-12). [PATCH /v1/posts/{id}](/docs/feed/posts/update) без единого изменяемого поля (`{}` или текст под именем `message`) отвечал `200` «Post updated», сделав два вызова в Битрикс24 и не изменив ничего.

**Стало**

Правка сообщения требует `message` с текстом по правилу самого Битрикс24: пустой, из одних пробелов, из одних тегов `[BR]`/`[br]`, не строка и не число, под другим именем поля — `400 MESSAGE_REQUIRED` до обращения к порталу, в тексте ошибки названо нераспознанное поле; конечное число принимается и записывается как текст. Удаление сообщения — только через [DELETE /v1/chats/{dialogId}/messages/{messageId}](/docs/chats/messages/delete). `userId` при удалении участника и каждый элемент `users` при добавлении обязаны быть положительным целым — числом или строкой из десятичных цифр без ведущих нулей и пробелов, не больше 2^53−1; иначе `400 INVALID_PARAMS` (у `users` названы индекс и тип элемента), отсутствующий `userId` или пустой `users` — `400 MISSING_PARAMS`. Значение уходит в Битрикс24 нормализованным числом. Строковые формы, которые портал разбирал сам и которые через прежний проброс проходили (`department<id>`, `structure<id>`, `network<id>`), теперь отклоняются — принимаются только ID пользователей. У правки сообщения и удаления участника на портал уходят только проверенные параметры (`MESSAGE`; `CHAT_ID` и `USER_ID`): прочие ключи тела, в том числе нативные ключи Битрикс24 в верхнем регистре (`URL_PREVIEW`, `IS_EDITED`, `ATTACH`, `KEYBOARD`), которые прежде доезжали вместе с телом, больше не передаются. Правка поста без единого из полей `text`, `title`, `recipients`, `files` — `400 MISSING_PARAMS` до обращения к порталу, нераспознанное поле названо. Вызов без тела запроса у правки сообщения, отвечавший `500`, теперь получает тот же `400 MESSAGE_REQUIRED`.

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

Проверьте, что правка сообщения всегда несёт текст в поле `message`, а участники чата передаются числами (или строками из цифр без ведущих нулей) — `userId` скаляром, `users` плоским массивом. Правка поста должна нести хотя бы одно изменяемое поле. Если в теле правки сообщения или удаления участника передавались нативные ключи Битрикс24 сверх документированных полей — они больше не действуют. Вызовы, которые прежде отвечали успехом с этими телами, на самом деле удаляли сообщение, трогали не того участника или ничего не меняли — теперь они получают отказ с объяснением.

**Затронутые эндпоинты:** [PATCH /v1/chats/{dialogId}/messages/{messageId}](/docs/chats/messages/update), [POST /v1/chats/{chatId}/users](/docs/chats/members/add), [DELETE /v1/chats/{chatId}/users](/docs/chats/members/remove), [PATCH /v1/posts/{id}](/docs/feed/posts/update).

### BC-0912-4: числовой идентификатор в пути ручек чатов и уведомлений проверяется до обращения в Битрикс24

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

**Было**

Идентификатор из пути читался нестрого: значение с лишним хвостом или дробной частью (`125abc`, `125.9`) уходило в Битрикс24 как 125, и операция выполнялась над записью 125 — ответ `200` или `204`, как для правильного вызова. Полностью нечисловое значение (`abc`) уходило пустым и отклонялось уже Битрикс24 (`403` или `422`).

**Стало**

Идентификатор обязан быть положительным целым числом в канонической записи: без знака, ведущего нуля, дроби, экспоненты и пробелов. Иначе ручка отвечает `400` до обращения в Битрикс24: для `chatId` — `INVALID_CHAT_ID` (как уже отвечало [PATCH /v1/chats/:chatId](/docs/chats/management/rename)), для `messageId`, `fileId` и `id` уведомления — `INVALID_PARAMS`. Текст ошибки называет параметр. Корректные идентификаторы обрабатываются как прежде.

**Затронутые эндпоинты:** [DELETE /v1/notifications/:id](/docs/notifications/delete), [GET /v1/chats/files/:fileId](/docs/chats/files/file-get), [PATCH /v1/chats/:dialogId/messages/:messageId](/docs/chats/messages/update), [DELETE /v1/chats/:dialogId/messages/:messageId](/docs/chats/messages/delete), [POST /v1/chats/:chatId/leave](/docs/chats/management/leave), [POST /v1/chats/:chatId/owner](/docs/chats/management/owner), [POST /v1/chats/:chatId/users](/docs/chats/members/add), [DELETE /v1/chats/:chatId/users](/docs/chats/members/remove), [POST /v1/chats/:chatId/files](/docs/chats/files/upload), [GET /v1/chats/:chatId/folder](/docs/chats/files/folder).

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

Передавать идентификатор так, как его вернул API: только цифры. Если идентификатор собирается из строки, убрать хвосты и разделители до подстановки в путь. Клиенты, уже передающие идентификаторы числом, ничего не меняют.

### FIX-0912-5: предсуществующая конфигурация NodeSource переживает обрыв установки рантайма

**Было**

При деплое рантайма `node20*` на переиспользованную или вручную настроенную виртуальную машину
Вайбкод на время установки убирал с рабочего пути ваши файлы
`/etc/apt/sources.list.d/nodesource.list` и `nodesource.sources` и возвращал их в конце. Если шаг
установки обрывался — по таймауту или при разрыве соединения, — файлы на сервере так и оставались
удалёнными: дальнейшие установки и обновления Node.js через apt переставали использовать ваш
репозиторий до ручного восстановления.

**Стало**

Обрыв шага установки больше не теряет вашу конфигурацию: она остаётся на сервере, и следующий
деплой рантайма возвращает файлы на рабочий путь сам. Если установка NodeSource прошла успешно, на
рабочем пути остаётся именно ваш файл, а созданный установщиком удаляется. Восстанавливаются
именно эти два файла: `/etc/apt/preferences.d/nodejs`, `nsolid` и ключ
`/usr/share/keyrings/nodesource.gpg` установщик перезаписывает, и платформа их не возвращает. Если
ваш `nodesource.sources` создан обычной командой установки NodeSource, он совпадает с файлом
установщика содержимое-в-содержимое, платформа их не различает и при обрыве установки может удалить
такой файл — восстановить его можно той же командой. 

Отдельный случай: если рядом с ним лежит ваш `nodesource.list`, который **активной строкой называет
тот же репозиторий NodeSource и тот же выпуск** (`nodistro`), платформа **при обычном деплое, без
всякого обрыва** снимает с рабочего пути свой файл. Он не удаляется, а остаётся рядом под именем с
суффиксом `.vibe-node20-conflict.disabled`; apt его не читает, удалить можно вручную. Если там уже
лежит точно такой же файл от прошлой такой починки, повторный просто удаляется с рабочего пути. Ради чего: если
ваша строка называет тот же репозиторий с другим ключом, apt отказывается читать список источников
целиком — на сервере перестают ставиться любые пакеты. Если ключ тот же, конфликта нет, но свой файл
платформа всё равно снимает: на рабочем пути остаётся ваш. Если ваш `.list` указывает на другой
репозиторий — например, на ваше зеркало, — или строка закомментирована, платформа ничего не трогает.

Если вы сами замените файл на рабочем пути между установками, ваш выбор останется нетронутым, а
сохранённая копия прежней конфигурации будет лежать рядом под именем с суффиксом
`.vibe-node20-parked.disabled` — apt её не читает, удалить её можно вручную. **Одно исключение:**
если вы вернёте конфигурацию не своим файлом, а самой командой установки NodeSource, платформа не
отличит её от собственной, снимет и вернёт на путь прежнюю сохранённую копию. На машинах, где своей
конфигурации NodeSource не было, поведение не изменилось.

### FIX-0912-6: подписка Маркетплейса перестала быть условием и для аккаунтов на собственном сервере

**Было**

В блоке `activation.marketTrial` ответа [GET /v1/cowork/state](/docs/cowork/state) причина `not_required_for_data` приходила только облачным аккаунтам подписочной модели и только после включения соответствующей настройки платформы. Аккаунт на собственном сервере, которому пробный период предлагался (`available: true`), получал это предложение и при включённой настройке.

**Стало**

Причина по-прежнему приходит только аккаунтам подписочной модели и только после включения соответствующей настройки платформы, но теперь — обоих типов: аккаунт на собственном сервере, которому пробный период предлагался бы, получает вместо `available: true` значение `available: false` с причиной `not_required_for_data` — так же, как облачный. Без этой настройки ответ прежний у обоих типов. Набор из восьми причин не изменился, порядок их выбора тоже: причина ступени, если она есть, по-прежнему сильнее. Клиенту делать ничего не нужно — ветка по умолчанию на любое `false` прячет шаг включения сама.