# Изменения API: 9 октября 2026 [← Журнал изменений](/docs/changelog) · [Октябрь 2026](/docs/changelog/2026-10) ### BC-1009-1: Порядок в batch-подкомандах шаблонов документов и событий календаря > Поддержка старого формата до: не предусмотрена **Было** В [POST /v1/batch](/docs/batch) подкоманды `list` и `search` для `doc-templates` и `calendar-events` могли принять `sort` или `order` и ответить успешно, не сохранив запрошенный порядок. **Стало** Такая подкоманда получает `INVALID_SORT_FIELD` до вызова Битрикс24. Если все подкоманды отклонены, ответ — HTTP 400 `INVALID_REQUEST` с кодом подкоманды в `data.errors`. В смешанном запросе успешные подкоманды продолжают выполняться. **Что делать интеграторам** Для `doc-templates` запрашивайте полный отсортированный набор через [GET /v1/doc-templates](/docs/entities/doc-templates/list) с параметром `sort`. Для `calendar-events` уберите `sort` и `order` из batch-подкоманды: список возвращается в фиксированном порядке по времени начала. ### FIX-1009-2: Удаление отсутствующего изображения товара возвращает 404 **Было** [DELETE /v1/catalog-products/:productId/images/:imageId](/docs/entities/catalog-products/images-delete) отвечал `422 BITRIX_ERROR`, если изображение уже удалено, принадлежит другому товару или не существует. **Стало** В этих случаях ответ — `404 ENTITY_NOT_FOUND`, как при чтении изображения. Успешное удаление по-прежнему возвращает `200` и `data.deleted: true`. **Влияние на интеграторов** При повторе удаления после потерянного ответа учитывайте `404 ENTITY_NOT_FOUND`. Отсутствие изображения можно проверить по списку изображений товара. ### FIX-1009-3: Ручная регистрация ИИ-модели сообщает о неверном типе поля **Было** `POST /v1/ai/credentials/:id/models` возвращал `500 internal_error`, если `name` был числом, `contextLength` — дробным числом или `maxOutputTokens` — строкой. **Стало** Неверные типы этих полей, дробные значения и целые числа вне диапазона от `-2147483648` до `2147483647` для `contextLength` и `maxOutputTokens` возвращают `400 invalid_request`. Сообщение указывает поле, которое нужно исправить. `null` и отсутствие необязательных полей сохраняют прежние значения по умолчанию. ### BC-1009-4: fields в пакетных запросах каталога возвращает карту полей без обёртки > Поддержка старого формата до: не предусмотрена **Было** В `POST /v1/catalog-measures/batch`, `POST /v1/catalog-vat-rates/batch`, `POST /v1/catalog-documents/batch`, `POST /v1/catalog-document-elements/batch`, `POST /v1/catalog-skus/batch` и `POST /v1/catalog-offers/batch` с `action: "fields"` карта полей находилась в `data[i].data.<ключ>`, где ключ — соответственно `measure`, `vat`, `document`, `documentElement`, `sku` или `offer`. **Стало** Каждый элемент возвращает карту дескрипторов непосредственно в `data[i].data`. Например, вместо `data[i].data.sku.id` поле доступно в `data[i].data.id`. **Что делать интеграторам** Уберите чтение промежуточного ключа из обработки `action: "fields"` этих шести пакетных методов. Имена полей и содержимое дескрипторов сохраняются. ### NEW-1009-5: стена квоты Cowork/Code предлагает сброс лимитов по праву акции Отказ `402 cowork_quota_exhausted` на [POST /v1/chat/completions](/docs/ai/chat/completions), [POST /v1/audio/transcriptions](/docs/ai/audio/transcriptions) и [POST /v1/images/generations](/docs/ai/images) несёт блок `limitReset`, когда у пользователя есть право сбросить лимиты, которое можно потратить прямо сейчас (`seatAlreadyReset: false`). Блок тот же, что в [GET /v1/cowork/me](/docs/cowork/me), а право тратится методом `POST /v1/cowork/limits/reset`. Тот же блок приходит в предупреждении `COWORK_QUOTA_FALLBACK` синхронного ответа резервной модели. Без такого права ключа нет и тело ответа прежнее, поэтому проверяйте наличие ключа. ### BC-1009-6: Списки действий и роботов отклоняют сортировку > Поддержка старого формата до: не предусмотрена **Было** `sort` и `order` в запросах списка действий и роботов могли возвращать успешный ответ, хотя порядок кодов не менялся. **Стало** Для [GET /v1/bizproc-activities](/docs/entities/bizproc-activities/list) и [GET /v1/bizproc-robots](/docs/entities/bizproc-robots/list) любой `sort` или `order` возвращает `400 INVALID_SORT_FIELD`. В [POST /v1/batch](/docs/batch), `POST /v1/bizproc-activities/batch` и `POST /v1/bizproc-robots/batch` соответствующий подвызов получает `INVALID_SORT_FIELD` в своём поле ошибки. **Что делать интеграторам** Уберите `sort` и `order` из этих запросов. Если нужен определённый порядок, отсортируйте полученные коды в своём приложении. ### FIX-1009-7: Пароль SSH открытого сервера подходит к пользователю из выдачи доступа **Было** После перевода сервера в режим `OPEN` метод [GET /v1/infra/servers/{id}/ssh](/docs/infra/access/ssh) отдавал пару `sshUser` и `sshPassword`, в которой пароль был задан другому пользователю. Если `sshUser` равен `ubuntu`, вход по паролю под `ubuntu` отклонялся. Вход по ключу работал. **Стало** Пароль задаётся тому пользователю, которого возвращает поле `sshUser`, поэтому вход по паролю под ним проходит. Формат ответа не меняется. Как и раньше, каждый переход в `OPEN` выдаёт новый пароль, а прежние пароли перестают действовать. ### FIX-1009-8: OpenAPI описывает пользовательские поля счетов **Было** Шесть работающих методов пользовательских полей смарт-счетов `/v1/userfields/invoices` отсутствовали в OpenAPI и справочнике API Вайбкод: [список полей](/docs/userfields/smart-processes/list), [типы](/docs/userfields/smart-processes/types), [создание](/docs/userfields/smart-processes/create), [чтение](/docs/userfields/smart-processes/get), [обновление](/docs/userfields/smart-processes/update) и [удаление](/docs/userfields/smart-processes/delete). Агенты и генераторы клиентов, читающие спецификацию, не видели эти методы. **Стало** Методы включены в полную спецификацию, срез `crm` и справочник на обоих языках. Они используют тот же контракт пользовательских полей, что и `/v1/items/{entityTypeId}/userfields`, с фиксированным типом смарт-счёта `31`. Описаны параметры, запросы, ответы и отказы. Поведение методов не изменилось. Чтобы методы появились в генерируемом клиенте, обновите его из актуальной спецификации. **Влияние на интеграторов** Действий не требуется. ### FIX-1009-9: OpenAPI описывает привязки дел к CRM-сущностям **Было** Четыре работающих метода привязок дел отсутствовали в OpenAPI и справочнике API Вайбкод: [GET /v1/activities/{activityId}/bindings](/docs/entities/activities/bindings/list), [POST /v1/activities/{activityId}/bindings](/docs/entities/activities/bindings/bind), [DELETE /v1/activities/{activityId}/bindings](/docs/entities/activities/bindings/unbind) и [POST /v1/activities/{activityId}/bindings/move](/docs/entities/activities/bindings/move). Агенты и генераторы клиентов не видели эти методы в спецификации. **Стало** Методы включены в полную спецификацию, срез `crm` и справочник на обоих языках. Описаны параметры, запросы, ответы и отказы, включая передачу параметров удаления через query или JSON-тело. Поведение методов не изменилось. Обновите генерируемый клиент из актуальной спецификации, чтобы в нём появились эти методы. **Влияние на интеграторов** Действий не требуется. ### FIX-1009-10: Строгая проверка id полей шаблонов реквизитов **Было** В маршрутах полей шаблонов реквизитов нечисловой хвост id молча отбрасывался: например, `12abc` превращался в `12`, и изменение или удаление могло затронуть другое поле. **Затронутые эндпоинты:** [GET /v1/requisite-presets/{presetId}/fields](/docs/entities/requisite-presets/preset-fields/list), [GET /v1/requisite-presets/{presetId}/fields/schema](/docs/entities/requisite-presets/preset-fields/schema), [GET /v1/requisite-presets/{presetId}/fields/available](/docs/entities/requisite-presets/preset-fields/available), [POST /v1/requisite-presets/{presetId}/fields](/docs/entities/requisite-presets/preset-fields/create), [GET /v1/requisite-presets/{presetId}/fields/{id}](/docs/entities/requisite-presets/preset-fields/get), [PATCH /v1/requisite-presets/{presetId}/fields/{id}](/docs/entities/requisite-presets/preset-fields/update), [DELETE /v1/requisite-presets/{presetId}/fields/{id}](/docs/entities/requisite-presets/preset-fields/delete). **Стало** Некорректный `presetId` или id поля отклоняется до обращения к Битрикс24: HTTP 400 с кодом `INVALID_PRESET_ID` или `INVALID_FIELD_ID`. Допустимы только целые десятичные числа от `1` до `9007199254740991` без знака, ведущих нулей, пробелов, дробной части, экспоненты и нечислового хвоста. **Для интеграторов** Передавайте id целым числом в указанном диапазоне и формате. ### FIX-1009-11: демо Vibe+, включённое в Битрикс24, открывает доступ на .com **Было** Если демо Vibe+ включали на стороне Битрикс24, а не кнопкой в кабинете Вайбкод, платформа о нём не знала. Создание сервера, агента или бота и выпуск ключа получали отказ `402` с кодом `INT_VIBE_PLUS_REQUIRED`, хотя в Битрикс24 демо было активно. [GET /v1/me](/docs/keys-auth/me) с параметром `refresh=tariff` перечитывал только тариф, и продление демо на стороне Битрикс24 тоже оставалось незамеченным. **Стало** Прежде чем ответить `INT_VIBE_PLUS_REQUIRED`, платформа спрашивает Битрикс24 о демо Vibe+. Если демо активно, действие выполняется в режиме пробного периода, с теми же ограничениями, что и у демо, подключённого из кабинета. Запрос с `refresh=tariff` теперь перечитывает и срок демо. Если Битрикс24 не ответил, отказ остаётся прежним. **Влияние на интеграторов** Менять ничего не нужно. Агент, получивший `INT_VIBE_PLUS_REQUIRED` после включения демо в Битрикс24, может повторить действие. ### FIX-1009-12: окна пробуждения: запас не меньше платформенного, исходы по моменту подъёма **Было** Значение `lead` в окне [POST /v1/infra/servers/:id/wake-schedules](/docs/infra/wake-schedules/create) меньше платформенного запаса сокращало время на подъём сервера, и с таким запасом сервер не успевал подняться к моменту `cronExpr`. Исход `WOKEN` или `LATE` в ответе [GET /v1/infra/servers/:id/wake-schedules](/docs/infra/wake-schedules/list) не совпадал с моментом подъёма: сервер, поднявшийся за секунды до срока, получал `LATE`. Если в момент окна сервер уже работал и засыпал вскоре после него, платформа поднимала его повторно ради прошедшего срока и записывала `LATE`. **Стало** Платформенный запас стал нижней границей: меньшее значение `lead` сохраняется в окне как передано, но подъём начинается не позже, чем за платформенный запас до момента `cronExpr`. Исход и `firedAt` определяются по моменту, когда сервер перешёл в `RUNNING`. Срок, на который сервер уже работал, считается обслуженным, повторного подъёма и записи в истории окна нет. **Влияние на интеграторов** Действий не требуется. Сервер с `lead` меньше платформенного запаса теперь поднимается раньше и работает на это время дольше. ### FIX-1009-13: Ответ API на бесплатном тарифе называет тариф и подписку **Было** Отказ `402 MARKETPLACE_REQUIRED`, например при вызове [POST /v1/infra/servers](/docs/infra/servers/create), предлагал подключить только подписку Маркетплейса даже на бесплатном тарифе Битрикс24. **Стало** Для российского портала на прочитанном бесплатном тарифе поля `message`, `userMessage` и `hint` сообщают, что нужны платный тариф Битрикс24 и подписка BitrixGPT + Маркетплейс. Касса портала добавит оба в одну корзину. Ссылка для покупки остаётся прежней. На платном, демо-тарифе и при непрочитанном тарифе сохраняется прежний текст отказа. **Влияние на интеграторов** Менять интеграцию не требуется. Формат ответа, HTTP-статус и код ошибки сохраняются. Новое пояснение помогает пользователю понять, что необходимо приобрести для создания инфраструктуры. ### NEW-1009-14: Одиночные методы доступны в OpenAPI и справочнике API В `GET /v1/openapi.json` и справочник API добавлены описания шести уже работающих методов: [POST /v1/pages/{id}/publication](/docs/entities/pages), [POST /v1/pages/{id}/unpublish](/docs/entities/pages), [GET /v1/chats/events](/docs/chats/events/poll), [POST /v1/users/invite](/docs/entities/users/invite), [POST /v1/workflows/activity-log](/docs/automation/workflows/activity-log) и [GET /v1/warehouses/fields](/docs/entities/warehouses/fields). Агенты и генераторы клиентов могут обнаружить эти методы и прочитать их параметры, тела запросов, ответы и отказы. Поведение методов сохранено. ### FIX-1009-15: добавление товара в оплату отвечает 404 на немецком и казахском языках Битрикс24 **Было** [POST /v1/crm-payments/:id/products](/docs/entities/crm-payments/products-add) с товаром, который нельзя оплатить в этой оплате, отвечал `404 ENTITY_NOT_FOUND`, только если Битрикс24 работал на английском или русском языке. На немецком и казахском тот же отказ приходил как `422 BITRIX_ERROR` с текстом на языке Битрикс24. **Стало** Отказ отвечает `404 ENTITY_NOT_FOUND` на любом из этих языков. Для немецкого и казахского текст ошибки приходит на английском: `Product was not found.` **Влияние на интеграторов** Действий не требуется. Обработчик `404 ENTITY_NOT_FOUND` теперь срабатывает одинаково на всех языках Битрикс24. ### NEW-1009-16: настройки учёта рабочего времени по указанному сотруднику [GET /v1/workday/settings](/docs/workday/settings) принимает необязательный параметр `userId` и возвращает настройки учёта рабочего времени этого сотрудника, в том числе признак `ufTimeman` (ведётся ли учёт). Без параметра ответ, как и раньше, относится к пользователю, которому принадлежат токены ключа. Настройки другого сотрудника Битрикс24 отдаёт только при праве управлять рабочим временем всех сотрудников, иначе запрос отклоняется с ошибкой `422 BITRIX_ERROR`. Поле `admin` в настройках другого сотрудника не возвращается. Значение `userId`, которое не является положительным целым числом, отклоняется с ошибкой `400 INVALID_PARAMS`. ### NEW-1009-17: Расширения Коворка API Вайбкод поддерживает отдельный каталог расширений Коворка: создание карточек, проверку и загрузку версий, публикацию и скачивание опубликованных архивов. Корпоративные расширения доступны участникам своей компании; расширения поставщика доступны глобально. Публикация не устанавливает и не включает расширение у пользователя. Desktop API использует существующий scope `vibe:cowork`; scopes выданных ключей и API приложений не меняются. Изменения карточек защищены ревизией и ключом идемпотентности. Добавлен POST `/v1/cowork/portal-rest` для SDK: он сохраняет существующие права метода и READONLY, возвращает исходный native result и не повторяет native записи при неопределённом результате. Корпоративная публикация не требует модерации; архив UI+Node собирается локально. ### NEW-1009-18: Ссылка на описание подписки или тарифа в отказе 402 по AI-квоте Ответ `402 ai_quota_exhausted` с `reason: "wallet_off"` на маршрутах моделей, например на [чате](/docs/ai/chat/completions), [эмбеддингах](/docs/ai/embeddings) и [расшифровке аудио](/docs/ai/audio/transcriptions), несёт поле `details.learnMoreUrl`, когда подтверждено отсутствие оплаченного доступа к AI-моделям, в том числе при исчерпанной квоте демо. Это страница с описанием подписки или тарифа Битрикс24, в которые входит AI, а поле `message` в этом случае называет нужный продукт. При неподтверждённом состоянии доступа или других причинах отказа ответ прежний. ### BC-1009-19: Разрешение портала на ИИ в приложениях Connect > Поддержка старого формата до: не предусмотрена **Было** Партнёрское приложение Connect могло получить доступ к моделям по праву `vibe:ai` при согласии сотрудника без отдельного разрешения администратора портала. **Стало** Для партнёрского приложения Connect доступ к моделям по праву `vibe:ai` требует действующего разрешения администратора портала. Пока разрешения нет или оно отозвано, вызовы моделей, например [POST /v1/chat/completions](/docs/ai/chat/completions), возвращают `403 CONNECT_AI_NOT_PERMITTED`. Другие права ключа продолжают действовать. **Что делать интеграторам** Если сотрудник запрашивает разрешение администратора, текущая попытка подключения завершается отказом. В перенаправлении OAuth приходит `error=access_denied` и `error_description=admin_approval_requested`; при опросе устройства через `POST /v1/connect/token` ответ содержит те же значения. Это окончание попытки, а не сигнал продолжать опрос. После одобрения администратором начните новое подключение Connect. При `CONNECT_AI_NOT_PERMITTED` после отзыва разрешения обратитесь к администратору за повторным разрешением.