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

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

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

Стало

Правка сообщения требует message с текстом по правилу самого Битрикс24: пустой, из одних пробелов, из одних тегов [BR]/[br], не строка и не число, под другим именем поля — 400 MESSAGE_REQUIRED до обращения к порталу, в тексте ошибки названо нераспознанное поле; конечное число принимается и записывается как текст. Удаление сообщения — только через DELETE /v1/chats/{dialogId}/messages/{messageId}. 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}, POST /v1/chats/{chatId}/users, DELETE /v1/chats/{chatId}/users, PATCH /v1/posts/{id}.

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), для messageId, fileId и id уведомления — INVALID_PARAMS. Текст ошибки называет параметр. Корректные идентификаторы обрабатываются как прежде.

Затронутые эндпоинты: DELETE /v1/notifications/:id, GET /v1/chats/files/:fileId, PATCH /v1/chats/:dialogId/messages/:messageId, DELETE /v1/chats/:dialogId/messages/:messageId, POST /v1/chats/:chatId/leave, POST /v1/chats/:chatId/owner, POST /v1/chats/:chatId/users, DELETE /v1/chats/:chatId/users, POST /v1/chats/:chatId/files, GET /v1/chats/:chatId/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 причина not_required_for_data приходила только облачным аккаунтам подписочной модели и только после включения соответствующей настройки платформы. Аккаунт на собственном сервере, которому пробный период предлагался (available: true), получал это предложение и при включённой настройке.

Стало

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