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

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

NEW-1002-1: Рабочие и дневные отчёты

Рабочие и дневные отчёты доступны через API учёта дня. Рабочие отчёты можно читать, создавать, обновлять, отправлять и оценивать. Дневной отчёт можно прочитать и записать в свою запись рабочего времени. Сдача без reportId создаёт новый отчёт и сразу отправляет его. Отсутствующие и null-поля частичного обновления сохраняются.

NEW-1002-2: Платёжные системы и службы доставки

Добавлены /v1/pay-systems и /v1/delivery-services: полные списки, чтение по ID, создание, изменение, удаление и /handlers для выбора зарегистрированного обработчика. Требуются скоупы pay_system и delivery соответственно; одного sale недостаточно. Изменение и удаление доступны только системам на REST-обработчиках, с проверкой прав Б24. PATCH возвращает перечитанную запись, создание доставки — parent и profiles. Логотип передаётся как logo: [filename, base64], до 2 МиБ. Пагинации, регистрации обработчиков и generic batch у этих разделов нет.

NEW-1002-3: Действия оператора открытой линии

Действия оператора открытой линии дополнены пропуском диалога, пометкой клиента спамером, передачей сотруднику или в очередь и завершением диалога другого оператора. Пауза оператора читается, включается и выключается для владельца токена: сотрудника, выпустившего вебхук, или вызывающего сотрудника OAuth. Добавлены открытие чата клиента по коду коннектора и начало сессии. Все операции требуют imopenlines, записи запрещены для READONLY-ключа. Пометка спамом закрывает диалог и помечает клиента спамером.

Затронутые эндпоинты: POST /v1/openlines/operator/skip, POST /v1/openlines/operator/spam, POST /v1/openlines/operator/transfer, POST /v1/openlines/operator/finish-another, GET /v1/openlines/operator/pause, POST /v1/openlines/operator/pause, DELETE /v1/openlines/operator/pause, POST /v1/openlines/sessions/open, POST /v1/openlines/sessions/start.

NEW-1002-4: Управление ресурсами бронирования, типами и рабочими часами

Добавлены GET /v1/booking-resources/:id, POST /v1/booking-resources, PATCH|DELETE /v1/booking-resources/:id, список и CRUD /v1/booking-resource-types, а также GET|PUT|DELETE /v1/booking-resources/:id/slots. Нужен scope booking; запись требует READWRITE. Создание возвращает 201 и перечитанную карточку, PATCH — 200 и карточку, удаление — 204 без тела. Карточки возвращают переключатели уведомлений как boolean; существующий список ресурсов сохраняет Y/N.

PUT слотов заменяет весь набор часов, DELETE удаляет все слоты. Список типов обходит страницы по длине выдачи и игнорирует total Б24; максимум 500 типов. Уведомления клиентам по умолчанию включены в Б24: при необходимости выключайте все шесть is*NotificationOn явно. Будущие брони мешают удалению ресурса, активные ресурсы — удалению типа. Ошибки Б24 возвращаются 422; неизвестная запись — 404, некорректный id или форма тела — 400. На части облачных версий обновление типа требует новый code; прежний code отвергается как дубль.

PATCH ресурса с часами отказывается с 422 BOOKING_RESOURCE_SCHEDULE_CONFLICT: native update удаляет слоты. Неверная IANA-зона и нулевой размер слота возвращают 400 до вызова.

NEW-1002-5: Команды ботов и действия с уведомлениями

Добавлены GET /v1/chats/:dialogId/commands, POST /v1/chats/messages/:messageId/command и POST /v1/chats/messages/:messageId/unread с обязательным dialogId в теле. Доступны POST /v1/notifications/:id/answer, POST /v1/notifications/:id/confirm и GET /v1/notifications/search. Все требуют im; действия требуют записи. Подтверждение кнопки выполняет её действие и удаляет уведомление. Поиск использует курсор lastId.

NEW-1002-6: Клиенты брони и лист ожидания

Добавлены клиенты брони, типы клиентов и лист ожидания: чтение, создание, изменение, удаление, замена клиентов и перенос между бронью и очередью. PUT клиентов заменяет весь набор. Переносы удаляют исходную запись. Scope booking. Пустая запись листа ожидания допустима. Список обходит страницы независимо от total Битрикс24. Ресурсы с включёнными уведомлениями могут отправлять сообщения клиентам.

BC-1002-7: Коворк старается завершить начатую работу перед пятичасовым лимитом

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

Было

Чатовые запросы Коворка с инструментами продолжали обычную работу до исчерпания лимита окна. Явный именованный tool_choice требовал вызова выбранной функции.

Стало

Для включённой аудитории POST /v1/chat/completions при малом положительном остатке пятичасового окна просит модель кратко завершить начатую часть работы. Новый ход просит отложить до сброса окна и передаёт без инструментов. Это попытка завершения, без дополнительной квоты и гарантии исправности файлов. Прежние жёсткие пятичасовой, недельный и месячный лимиты сохраняются. JSON и структурированные ответы остаются без этого изменения; новых полей ответа нет.

В режиме завершения именованный tool_choice становится auto, поэтому ответ может содержать текст без вызова выбранной функции. При отложенном новом ходе вызова инструмента не будет. Изменение действует только после включения функции для соответствующей аудитории. Пока функция выключена, поведение прежнее; отдельного периода поддержки прежней гарантии после включения нет.

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

До включения для вашей аудитории проверьте обработку обычного текстового ответа даже при явно выбранной функции. Не требуйте безусловного tool_calls: покажите итог пользователю и завершите текущий ход без автоматического повторного запуска инструмента. Формат запросов и полей ответа не меняется. Отложенную работу продолжайте после сброса окна.

NEW-1002-8: CRM-чаты открытых линий и быстрые ответы

Участники CRM-чата открытой линии: POST|DELETE /v1/openlines/crm/chats/users. Сообщение клиенту от сотрудника или бота: POST /v1/openlines/crm/messages. Привязка CRM после создания лида из обращения: POST /v1/openlines/dialogs/:chatId/lead.

Быстрые ответы линии: GET|POST /v1/openline-configs/:lineId/quick-replies, PATCH|DELETE /v1/openline-configs/:lineId/quick-replies/:id. PATCH сохраняет пропущенный sectionId. Скоуп — imopenlines; записи требуют ключ с правом записи.

NEW-1002-9: Операторские действия принимают chat

POST /v1/openlines/operator/answer и /finish принимают chatId в форме chat<N> наряду с числом и числовой строкой. Идентификатор можно взять из event.data.chat.id или sessions[].chatId поиска сессий.

NEW-1002-10: Бот в открытой линии: действия сессии

Добавлены POST /v1/bots/:botId/openlines/session/operator, /transfer, /finish и /auto-message. Нужны оба скоупа imbot и imopenlines. Передача работает с состоянием сессии, тогда как выход бота из IM-чата меняет только участников. Автосообщение принимает WELCOME или DEFAULT с сообщением; ответ подтверждает вызов, а не доставку.

FIX-1002-11: Операторские действия отвергают неточные идентификаторы

POST /v1/openlines/operator/answer и /finish возвращают 400 INVALID_CHAT_ID для дробных чисел и чисел вне безопасного целого диапазона, в том числе числовых строк. Такой ввод больше не адресует соседний чат после округления.

FIX-1002-13: бронь многочастной загрузки сразу занимает место в потолке хранилища портала

Было

Заявленный объём при открытии многочастной загрузки (POST /v1/storage/objects/multipart/create) попадал в подсчёт занятого места не во всех случаях: при замене существующего объекта он не учитывался вовсе, а внутри короткого окна кэширования подсчёт не видел и только что открытую бронь. Портал под жёстким потолком хранилища мог открыть несколько загрузок подряд и забронировать суммарно больше потолка — отказ приходил позже, уже после заливки частей.

Стало

Заявленный объём учитывается с момента открытия загрузки, одинаково для всех случаев, включая замену существующего объекта. Успешное открытие загрузки по-прежнему отвечает HTTP 200 с теми же полями; изменилась только полнота учёта, поэтому загрузка, которая превышает потолок, теперь получает 507 STORAGE_QUOTA_EXCEEDED сразу, до создания сессии у провайдера, а не после заливки частей. Видимый размер заменяемого объекта до завершения загрузки не меняется. Брошенная загрузка перестаёт занимать место вместе с истечением своей сессии.

BC-1002-14: сортировка неподдерживаемых полей товаров сообщает об ошибке

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

Было

GET /v1/products и POST /v1/products/search принимали сортировку по полям, которые Bitrix24 не сортирует, например price, и возвращали HTTP 200 с порядком по умолчанию.

Стало

Сортировка по неподдерживаемому полю товара, включая price и raw-имя PRICE, возвращает HTTP 400 UNKNOWN_SORT_FIELD со списком поддерживаемых полей. Сортировка по поддерживаемым полям и по свойствам каталога PROPERTY_<n> сохраняет HTTP 200.

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

Уберите сортировку товаров по price, currency, catalogId, measure, полям НДС и изображений. Нужен порядок по цене — сортируйте ответ на своей стороне или берите цены из /v1/catalog-prices.

BC-1002-15: нечитаемый номер пользовательского поля смарт-процесса отбивается до обращения к порталу

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

Было

GET /v1/items/{entityTypeId}/userfields/{id} принимал в :id любую строку. Значение без цифр уходило на портал пустым, и запрос заканчивался ошибкой Битрикс24 о непереданном обязательном параметре. Значение с цифрами в начале молча обрезалось по первому постороннему символу: по :id со значением 7abc приходил ответ 200 с описанием поля с номером 7.

Стало

:id обязан быть целым положительным числом в обычной записи: только цифры, без ведущего нуля, знака, дробной части, экспоненты и пробелов, и не больше 9007199254740991. Иначе платформа Вайбкод отвечает 400 INVALID_PARAMS и называет параметр в тексте сообщения. Обращения к порталу при таком отказе не происходит.

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

Если номер поля берётся из списка полей смарт-процесса и подставляется как есть, менять нечего — такие вызовы работают как раньше.

Отказ теперь получают три класса значений, и различаются они тем, что приходило раньше:

• раньше приходило описание ЧУЖОГО поля под 200 — строка с цифрами в начале и посторонним хвостом (7abc читалось как 7), экспонента (7e2 читалось как 7, а не 700) и номер больше 9007199254740991 (при пересчёте съезжал на соседний). Эти вызовы возвращали не то, что вы просили, и молчали об этом;
• раньше приходило ПРАВИЛЬНОЕ поле под 200 — номер, записанный не в обычной форме: ведущий ноль (007), знак (+7), дробь (7.0), пробелы по краям. Такие вызовы работали верно и теперь получают 400. Это единственный класс, который правка ломает у исправно работавшей интеграции, — уберите лишние символы, оставив только цифры;
• раньше приходила ошибка портала — значение без цифр, в том числе системное имя поля вида UF_CRM_…. Теперь платформа Вайбкод отвечает 400 сама, до обращения к порталу.

Во всех трёх случаях подставьте числовой номер поля из списка полей ровно в том виде, в каком он там приходит.

Затронутые эндпоинты: GET /v1/items/{entityTypeId}/userfields/{id} и его короткий адрес для смарт-счетов GET /v1/userfields/invoices/{id}.

FIX-1002-16: список и поиск CRM-сущностей отвечают понятной ошибкой, когда не доехал entityTypeId

Было

Чтение сущности на методе crm.item.list — список GET /v1/items/{entityTypeId} (а также /v1/deals, /v1/leads, /v1/contacts, /v1/companies, /v1/invoices, /v1/quotes) и парный ему поиск POST /v1/{entity}/search — уходило в Битрикс24 даже тогда, когда обязательный аргумент entityTypeId до вызова не доезжал. Портал отбивал такой вызов своей ошибкой с кодом 100 — «Could not find value for parameter {entityTypeId}», — и клиент получал её как общий отказ без имени параметра и без подсказки, что чинить.

Стало

Платформа Вайбкод проверяет аргумент до обращения к Битрикс24 на обеих ручках и отвечает 400 с кодом MISSING_PARAMS. В сообщении названы метод, параметр и способ его передать: для /v1/items — сегмент пути {entityTypeId} и где взять значение (GET /v1/smart-processes), для остальных сущностей значение задаёт сама сущность, поэтому сообщение просит сообщить X-Request-Id ответа. Успешные чтения не затронуты — ответ HTTP 200 у них прежний.

NEW-1002-17: Управление участниками групп и мои группы

Добавлены POST, DELETE, PATCH /v1/workgroups/:groupId/users, POST /v1/workgroups/:groupId/invitations, PUT /v1/workgroups/:groupId/owner и GET /v1/me/workgroups. Скоуп sonet_group; записи запрещены READONLY-ключам. При частичном или пустом результате действий — 422 BITRIX_ERROR с processedUserIds и skippedUserIds внутри error. Приглашение уведомляет человека; смена владельца может добавить нового участника. Подробнее.

FIX-1002-18: сортировка сотрудников больше не блокирует чтение списка

Было

Распознанная сортировка по нескольким полям и сортировка UF_*, требующая нескольких страниц, возвращали 400 INVALID_SORT_FIELD в GET /v1/users, POST /v1/users/search и POST /v1/batch.

Стало

Те же запросы сохраняют успешный ответ. Запрошенный порядок целиком заменяется на id по возрастанию, а ответ содержит одно предупреждение SORT_FALLBACK_TO_ID с полем sort. Одиночное обычное поле не по id по-прежнему возвращает UNKNOWN_SORT_FIELD.

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

Обрабатывайте предупреждение по полю code, если для приложения важен запрошенный порядок сотрудников.

BC-1002-19: Регистрация ботов проверяет смену адреса и происхождение регистрации

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

Было

POST /v1/bots мог ответить 201 для прежней регистрации после смены адреса или при отсутствии записи в базе Вайбкод (#1059).

Стало

Регистрация, затронутая сменой адреса, сохраняется и возвращает 409 BOT_DOMAIN_REREGISTRATION_REQUIRED с data: { botId, code, needsReregistration: true }. Недоказанное происхождение возвращает 409 BOT_REGISTRATION_ORIGIN_UNPROVEN без изменения записи. Изменившаяся привязка ключа или адрес возвращает 409 BOT_REGISTRATION_CONTEXT_CHANGED, параллельная запись — 409 BOT_REGISTRATION_CONCURRENT.

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

Обрабатывайте эти отказы отдельно от успеха. Для нового бота используйте уникальный код и личный ключ с входящим вебхуком. Без прежней локальной записи OAuth и собственный токен не допускаются к регистрации. Истёкший legacy OAuth-токен обновляйте отдельно. Сохранённые Bot и ключ не удаляйте автоматически. Для Agent и Managed Bot используйте восстановление ресурса владельца, а если оно недоступно — поддержку.

FIX-1002-20: пустые POST, PUT и PATCH запросы V1 получают ошибку валидации

Было

Пустой запрос без тела и заголовка Content-Type к части методов V1 мог завершиться внутренней ошибкой HTTP 500.

Стало

Такой запрос доходит до валидации маршрута и возвращает документированную ошибку HTTP 400.

NEW-1002-21: SIP, исходящая линия и запись разговора

Интеграции телефонии через API Вайбкод могут управлять SIP-подключениями, выбирать исходящую линию для всего портала, читать настройки сотрудников с ключом приложения, прикладывать запись завершённого звонка и искать карточки CRM по номеру. Пароли доступны только на запись; вместо них приходят признаки наличия. Запись принимается как base64 mp3/wav до 2 MiB или публичный HTTPS URL, служебный URL загрузки не выдаётся.

NEW-1002-22: Задания бизнес-процессов

Добавлены GET /v1/bizproc-tasks, POST /v1/bizproc-tasks/:id/complete и POST /v1/bizproc-tasks/delegate. Список возвращает страницу заданий и следующую позицию. Завершение выполняет реальное согласование с решением approve, reject, ok или cancel. Делегирование передаёт задания другому сотруднику. Нужен скоуп bizproc, для действий — ключ с правом записи. Битрикс24 проверяет права и допустимость решения. Ошибка делегирования может последовать после передачи части заданий: перечитайте список перед повтором.

NEW-1002-23: Скачивание документов приложений и публичная ссылка

Добавлены скачивание DOCX, PDF и PNG для /v1/documents/:id со скоупом documentgenerator. Ключ READONLY подходит для скачивания. Если формат ещё создаётся, ответ содержит 409 DOCUMENT_NOT_READY. Размер файла ограничен 10 МиБ.

Публичная ссылка включается и отключается через POST /v1/documents/:id/public-url с телом { enabled: boolean }. Включённую ссылку можно открыть без ключа. Машинные ссылки документов приложений теперь ведут на маршруты API Вайбкод.

BC-1002-24: свой адрес эндпоинта принимает только провайдер custom-openai-compat

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

Было

Создание и правка ключа AI-провайдера (POST и PATCH /v1/ai/credentials) принимали поле credentials.baseUrl у любого провайдера. Проверку адреса — схему и доступность — проходило только значение провайдера custom-openai-compat; у openai, anthropic, openrouter и bitrix строка сохранялась как есть и на маршрут вызова всё равно не влияла: эти провайдеры ходят по платформенному адресу.

Стало

У всех провайдеров, кроме custom-openai-compat, поле credentials.baseUrl отклоняется: ответ 400, код base_url_not_supported. Ключ без этого поля создаётся и правится как раньше. Свой адрес эндпоинта по-прежнему задаётся ключом провайдера custom-openai-compat, где значение проверяется при сохранении и хранится в нормализованном виде.

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

Уберите credentials.baseUrl из запросов создания и правки ключей всех провайдеров, кроме custom-openai-compat. Значение и так не влияло на то, куда уходил вызов, поэтому поведение уже созданных ключей не меняется — правка нужна только самому запросу.

NEW-1002-25: Журнал звонков и комментарии ленты

Добавлены личный журнал звонков, удаление записи и получение чата через /v1/calls/log. Получение чата может создать личный чат и требует ключ с записью. Чтение комментариев пользователя через GET /v1/posts/comments возвращает ID ленты и блога отдельно; DELETE /v1/feed-comments/:id удаляет комментарий события ленты. Ссылки с credentials скрыты. Отсутствующая запись журнала возвращает 404 вместо молчаливого успеха Б24.

NEW-1002-26: Коннекторы подготовленных сервисов и публичные документы OAuth

POST /v1/connectors/mcp поддерживает инструменты подготовленных сервисов с кодом. Вызовы сохраняют общие проверки доступа и подтверждение записи. Настройка подключения к внешнему сервису остаётся обязательной.

Для серверов OAuth с поддержкой CIMD идентификатором клиента может служить HTTPS-адрес неизменяемого публичного документа. Документ доступен без ключа и не содержит секрета клиента. Существующие ручные настройки и динамическая регистрация DCR сохраняются. Подробнее — фундамент коннекторов.

FIX-1002-27: именной промокод удалённого адресата не может погасить никто

Было

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

Стало

Адресат снимается с промокода вместе с удалением аккаунта, и погасить код больше не может никто — ни адресат, ни кто-либо другой: ни одна действующая почта с адресатом кода не совпадает. Код, который на момент удаления был свободен, при этом ещё и закрывается, и попытка погашения получает общий отказ COUPON_INVALID — тот же, которым отвечает код, погашенный или истёкший до удаления.

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

Промокоды без адресата и промокоды, выписанные на действующие аккаунты, отвечают как раньше.

NEW-1002-28: Перенос в базе знаний и типы полей модуля

POST /v1/note/collections/:id/move меняет общий порядок коллекций. POST /v1/note/documents/:id/move переносит документ вместе с поддеревом в коллекцию или под другого родителя. Ответ содержит перечитанный объект. Поля назначения необязательны, позиция допускает отрицательные значения.

GET /v1/userfields/types?moduleId=crm возвращает типы полей модуля в форме массива с userTypeId и description, без внутренних ключей. Нужен скоуп запрошенного модуля. Для сотрудников типы по-прежнему недоступны.