# Изменения API: 13 октября 2026 [← Журнал изменений](/docs/changelog) · [Октябрь 2026](/docs/changelog/2026-10) ### BC-1013-1: Адрес приложения вне платформы: только https, не ключом приложения или сервера > Поддержка старого формата до: не предусмотрена **Было** [POST /v1/apps](/docs/apps/create), [PATCH /v1/apps/{id}](/docs/apps/update) и [POST /v1/apps/{id}/publish](/docs/apps/publish) принимали в `appUrl` любой адрес `http://` или `https://`. Опубликовать приложение с адресом вне платформы мог любой ключ, которому разрешено менять приложение. **Стало** Адрес вне платформы принимается только публичный `https://`, иначе ответ `400 APP_URL_UNSAFE`. Опубликовать приложение с адресом, который не обслуживает действующий сервер этого аккаунта на платформе (внешний хост или домен, чей сервер удалён), или перевести на такой адрес опубликованное приложение можно из кабинета платформы Вайбкод или личным ключом. Ключ приложения, ключ [Connect-партнёра](/docs/partner-connect), ключ, привязанный к серверу, ключ Коворка, ключ с назначением, управляющий ключ и рабочий ключ агента или управляемого бота получают `403 EXTERNAL_URL_ACTOR_NOT_ALLOWED`. Если возможность недоступна для аккаунта, ответ `403 EXTERNAL_URL_DISABLED`. Параллельная смена адреса или статуса даёт `409 APP_URL_CONFLICT`. Правки, которые не меняют адрес и статус, и смена адреса неопубликованного приложения правилом ключей не проверяются. **Что делать интеграторам** Переведите адреса приложений вне платформы на `https://`. Публикуйте такие приложения из кабинета платформы Вайбкод или личным ключом. На `409 APP_URL_CONFLICT` перечитайте приложение и повторите запрос. ### FIX-1013-2: перевыпуск отозванного ключа API отказывает до создания нового ключа **Было** [POST /v1/keys/:id/rotate](/docs/management-keys) для отозванного ключа API (`vibe_api_`) начинал выпуск нового ключа и заканчивался ответом `500 KEY_ROTATION_FINALIZE_FAILED`. Новый ключ при этом оставался созданным, а перевыпуск и удаление обоих ключей отвечали `409 KEY_ROTATION_RECOVERY_REQUIRED`, пока новый ключ не удалят. **Стало** Перевыпуск отозванного ключа API сразу отвечает `409 KEY_NOT_ACTIVE`. Новый ключ не создаётся, исходный ключ не меняется. Перевыпуск действующего и заблокированного ключа работает как прежде. **Влияние на интеграторов** Менять ничего не нужно. Отказ `409 KEY_NOT_ACTIVE` уже описан для этого метода, а удалять лишний ключ после такой попытки больше не придётся. ### NEW-1013-3: настройка входа пользователей приложения через SDK Новый метод `GET /v1/app-user-signin/servers/{serverId}/setup` отдаёт всё, что нужно, чтобы подключить к приложению на сервере вход пользователей без Битрикс24 через SDK платформы Вайбкод: адреса возврата для каждого адреса приложения, хранилище под размещение, установку в три шага, переменные окружения и шаги регистрации у провайдеров входа. Метод только читает. Он доступен владельцу сервера его ключом с правом `vibe:infra` на портале этого сервера; без права метод отвечает `403 INFRA_SCOPE_REQUIRED`. Ключ, привязанный к приложению, читает настройку только сервера этого приложения. Чужой сервер, сервер другого приложения для такого ключа и запрос в контексте другого портала того же владельца получают `404 SERVER_NOT_FOUND`. Пока функция не включена для владельца ключа, метод отвечает `404 ROUTE_NOT_FOUND`. Поле `sdk` равно `null`, пока в метаданных выпусков платформы не записана ни одна версия пакета. ### NEW-1013-4: слот appUserSignIn.setup в ответе /v1/me В `data.capabilities` ответа `GET /v1/me` появилась группа `appUserSignIn` со слотом `setup` — доступна ли владельцу ключа настройка входа пользователей приложения через SDK платформы. Пока функция не включена, слот приходит с `available: false` и `reason: "FEATURE_DISABLED"`. Остальные поля ответа не меняются. ### NEW-1013-5: Ремонт сервера сообщает, что у платформы нет канала на машину Если платформа не может переустановить агента на сервере, ремонт теперь называет причину машинным кодом `REPAIR_NO_TRANSPORT`. Когда отказ известен заранее, [POST /v1/infra/servers/{id}/repair](/docs/infra/lifecycle/repair) отвечает `422`: такой сервер нужно пересоздать или восстановить из бэкапа, если он есть. Если платформа не смогла попасть на сервер уже в ходе ремонта, [GET /v1/infra/servers/{id}/repair-status](/docs/infra/lifecycle/repair-status) возвращает `status: "failed"`, а текст `data.error` начинается с `REPAIR_NO_TRANSPORT:`. Повторите ремонт позже, а если отказ сохраняется, обратитесь в поддержку. После такого отказа ремонт не усыпляет обратно сервер, который сам разбудил: сервер остаётся включённым, пока не уснёт по своей настройке простоя или пока вы не усыпите его сами. У остальных сбоев ремонта свой текст ошибки. Существующие запросы работают как раньше. ### NEW-1013-6: Копии базы приложения Для приложений в Галактике появились список копий SQLite и ручная копия файла базы: `GET /v1/infra/servers/:id/db/backups` и `POST /v1/infra/servers/:id/db/backups`. Ручной запрос возвращает `202 QUEUED`; завершение видно в списке. В информации о базе показываются возможность создания копий и последняя готовая копия файла по умолчанию. Ключи только для чтения могут просматривать копии; создание требует права записи. [Как создавать копии](/docs/infra/database). ### NEW-1013-7: Длительные команды с устойчивым результатом Длительные команды: [`POST /v1/infra/servers/:id/exec?async=true`](/docs/infra/deploy/exec) возвращает `202` и `operationId`. Обрыв ожидания не теряет результат команды. По существующему [`GET /v1/infra/operations/:operationId`](/docs/infra/deploy/operation-status) читаются исход и сохранённые stdout/stderr. Длительный режим доступен только на `STANDALONE` с таймаутом до 86400 секунд. Другие виды сервера, включая `GALAXY_APP`, получают `400 DURABLE_EXEC_UNSUPPORTED_SERVER_KIND` без запуска или синхронного перехода. Синхронный режим Galaxy и отдельной машины сохраняет предел 600 секунд. ### NEW-1013-8: Запуск спящего сервера сообщает, что свободной мощности пока нет Если для запуска спящего сервера с собственной машиной (любой вид, кроме `GALAXY_APP`) временно нет свободной мощности, [POST /v1/infra/servers/{id}/wake](/docs/infra/lifecycle/wake) с `wait=true` отвечает `503` с кодом `WAKE_NO_CAPACITY`. Так же завершается запуск такого спящего сервера при деплое и [POST /v1/infra/servers/{id}/start](/docs/infra/lifecycle/start) для такого сервера в статусе `error`. Вызовы без ожидания, то есть `/wake` без `wait=true` и `/start` для спящего сервера, отвечают как раньше, а сервер вскоре возвращается в статус `sleeping` со значением `WAKE_NO_CAPACITY` в поле `provisionErrorCode` ответа [GET /v1/infra/servers/{id}](/docs/infra/servers/get). Данные сервера сохранены. Автоматические попытки запуска такого сервера приостанавливаются на десять минут, и в это время `/wake` сразу отвечает `503 WAKE_NO_CAPACITY`. Сервер вида `GALAXY_APP` размещён на общей машине, и его касается только пауза этой машины: пока она не истекла, `/wake` и `/start` приложения сразу отвечают `503 WAKE_NO_CAPACITY`. Остальные ответы и поля приложения не меняются. Повторите запрос позже. Существующие запросы работают как раньше. ### BC-1013-9: Фильтр вариаций по датам отклоняется > Поддержка старого формата до: не предусмотрена **Было** [GET /v1/catalog-offers](/docs/entities/catalog-offers/list), [POST /v1/catalog-offers/search](/docs/entities/catalog-offers/search), [POST /v1/catalog-offers/aggregate](/docs/entities/catalog-offers/aggregate) и прежний `GET /v1/catalog-offers/aggregate` принимали фильтр по `dateCreate`, `timestampX`, `dateActiveFrom` и `dateActiveTo` и передавали его в Битрикс24. Метод Битрикс24 фильтры по датам не применяет, поэтому ответ `200` содержал все вариации каталога, а оба агрегата считались по всему каталогу вместо запрошенного периода. Так же вёл себя списочный подвызов вариаций в обоих batch-маршрутах. Широкий диапазон дат в поиске к тому же разбивался на окна, каждое окно возвращало те же строки, и в ответ приходило ложное предупреждение `WINDOW_TRUNCATED`. **Стало** Фильтр по любому из этих четырёх полей отклоняется до вызова Битрикс24. Одиночные маршруты и оба агрегата отвечают `400 UNKNOWN_FILTER_FIELD`. В списочном подвызове batch тот же код приходит в поле ошибки своего подвызова, остальные подвызовы выполняются. Разбиение поиска вариаций на временные окна больше не включается. Фильтры по остальным полям работают как прежде, сами поля дат по-прежнему приходят в ответе, а агрегат без фильтра по датам считается как раньше. **Что делать интеграторам** Уберите поля дат из фильтра вариаций на всех перечисленных ниже маршрутах, включая списочные подвызовы batch. Чтобы отобрать вариации по дате, запросите их без фильтра по дате и отберите по `dateCreate` или `timestampX` из ответа. Агрегат за период считайте на своей стороне по тем же строкам — отбора по дате у агрегата нет, а в его ответе нет строк, по которым можно отобрать. **Затронутые эндпоинты:** [GET /v1/catalog-offers](/docs/entities/catalog-offers/list), [POST /v1/catalog-offers/search](/docs/entities/catalog-offers/search), [POST /v1/catalog-offers/aggregate](/docs/entities/catalog-offers/aggregate), прежний `GET /v1/catalog-offers/aggregate`, [POST /v1/{entity}/batch](/docs/batch), [POST /v1/batch](/docs/batch). ### FIX-1013-10: непрочитанные тариф и подписка на создании сервера отвечают только 403 **Было** [POST /v1/infra/servers](/docs/infra/servers/create) в части случаев отвечал на `PORTAL_TARIFF_UNREADABLE` и `PORTAL_SUBSCRIPTION_UNREADABLE` статусом `402`, хотя таблица кодов обещает этим кодам `403`. Клиент, ветвящийся по статусу, принимал такой отказ за пейвол и предлагал покупку, которая его не снимает. **Стало** Оба кода приходят только со статусом `403`: поле `details.requiredTariffs` пустое, покупка тарифа или подписки отказ не снимает, средство названо в `userMessage`. Коды пейвола (`MARKETPLACE_REQUIRED`, `KZ_PAID_ONLY`, `UZ_PAID_ONLY`, `BY_PAID_ONLY`, `INT_TARIFF_REQUIRED`, `INT_VIBE_PLUS_REQUIRED`, триальные и биллинговые) по-прежнему отвечают `402`. Ответ `201` на успешном создании не меняется. **Влияние на интеграторов** Клиенту, который разбирает отказ по `error.code`, менять ничего не нужно. Ветвление по статусу больше не принимает этот отказ за пейвол. ### FIX-1013-11: поля услуги учитывают каталог **Было** [GET /v1/catalog-services/fields](/docs/entities/catalog-services/fields) возвращал только статические поля с предупреждением `fields_partial`, даже при переданном `iblockId`. **Стало** При переданном `iblockId` и успешном получении метаданных из Битрикс24 ответ включает свойства каталога без предупреждения `fields_partial`. Без `iblockId` или при недоступных метаданных сохраняется ответ со статическими полями и предупреждением. **Влияние на интеграторов** Чтобы получить свойства каталога, передавайте его `iblockId`. ### FIX-1013-12: Чек-лист сообщает об отсутствующей задаче **Было** Маршруты `/v1/tasks/:taskId/checklist` и `/v1/tasks/:taskId/checklist/:itemId`, включая действия `complete` и `renew`, возвращали `422 BITRIX_ERROR`, когда Битрикс24 сообщал `TASK_NOT_FOUND_OR_NOT_ACCESSIBLE`. **Стало** Этот отказ возвращается как `404 TASK_NOT_FOUND`. Отсутствующий пункт по-прежнему возвращает `404 NOT_FOUND`. Отказы по скоупу и ограничению частоты сохраняют свои статусы. ### NEW-1013-13: обмен токена Атласа после новой регистрации портала в Атласе Портал, заново зарегистрированный в Атласе, получает новый `tid`, и его люди приходят с новыми `sub`. `POST /v1/connect/atlas/token` с токеном того же издателя и нового `tid` переносит закреплённую личность пользователя портала на новую регистрацию и выдаёт ключ, если портал подтверждает, что номер пользователя по-прежнему у того же человека. Если подтвердить это не удалось, ответ — `403` `atlas_identity_changed` с новым значением `details.reason`: `atlas_tenant_changed_unverified`. Если портал называет другого владельца номера, ответ — `403` `atlas_identity_changed` с `details.reason` `portal_occupant_changed`. Если личность закреплена за другим издателем или токен несёт тот же `tid` с другим `sub`, ответ по-прежнему — `403` `atlas_identity_changed` с `details.reason` `atlas_subject_changed`. `POST /v1/connect/atlas/renew` закрепление не переносит: после переноса ключ, выданный по прежней регистрации, не продлевается, нужен новый обмен. ### BC-1013-14: Отсутствующий график рабочего дня отвечает ошибкой > Поддержка старого формата до: не предусмотрена **Было** [`GET /v1/workday/schedule`](/docs/workday/schedule) для несуществующего или удалённого графика отвечал HTTP 200 с `data: []`. **Стало** Такой запрос отвечает HTTP 404 с кодом `ENTITY_NOT_FOUND`. Существующий график по-прежнему возвращается в `data`. **Что делать интеграторам** Определяйте отсутствие графика по HTTP 404 и `error.code`, а не по пустому `data`. ### FIX-1013-15: Пакетный список файлов и папок учитывает папку **Было** Вызовы `list` в `POST /v1/files/batch` и `POST /v1/folders/batch` теряли переданный идентификатор папки и получали отказ Битрикс24. **Стало** Пакетный список читает содержимое указанной папки: `folderId` для файлов, `parentId` для папок. Параметр передаётся в `calls[].params` или `calls[].params.filter`. Если не удалось получить непустой скалярный параметр, ошибка `MISSING_REQUIRED_PARAMS` приходит в `data[i].error` внутри ответа HTTP 200. Остальные подвызовы продолжают выполняться. При заданном прямом скалярном параметре массив, объект или `null` в одноимённом ключе `filter` приводит к ошибке подвызова `INVALID_FILTER_OPERATOR`. То же ограничение действует для `list` файлов и папок в глобальном `POST /v1/batch`. **Влияние на интеграторов** Правильный запрос менять не нужно. Проверяйте ошибки каждого подвызова. Подробнее — [Пакетные вызовы](/docs/batch). ### FIX-1013-16: пакетный список каталога учитывает выбор полей **Было** Действие `list` в `POST /v1/catalog-products/batch`, `POST /v1/catalog-services/batch`, `POST /v1/catalog-skus/batch` и `POST /v1/catalog-offers/batch` могло возвращать ошибку подвызова `CALL_FAILED` об обязательных полях выборки даже с указанным `filter.iblockId`. **Стало** Без `select` и с `select: ["*"]` возвращается тот же сокращённый набор полей, что у одиночного списка и поиска. Явный `select` учитывает имена полей по тому же правилу. Требования к обязательным полям явной выборки сохраняются, ошибка одного подвызова не мешает остальным. **Влияние на интеграторов** Менять запрос списка без `select` не требуется. Если выборка указана явно, включайте в неё `id` и `iblockId`. ### FIX-1013-17: Проверка ID сообщений, команд и файлов бота **Было** Некорректные `messageId`, `commandId` и `fileId` в пути `/v1/bots/:botId/...` передавались в Битрикс24 как ноль, дробное число или `null`. Причина отказа зависела от ответа портала. **Стало** Платформа Вайбкод возвращает `400 INVALID_PARAMS` до вызова Битрикс24. ID в пути должен быть положительным целым числом от `1` до `9007199254740991`, без знака, ведущих нулей, дроби, экспоненты и пробелов. Обработка строкового `dialogId` сохраняется. **Влияние на интеграторов** Корректные положительные ID передаются как раньше. При `400 INVALID_PARAMS` исправьте указанный в ошибке сегмент пути. **Затронутые эндпоинты:** [GET /v1/bots/:botId/messages/:messageId](/docs/bots/messages/get), [PATCH /v1/bots/:botId/messages/:messageId](/docs/bots/messages/update), [DELETE /v1/bots/:botId/messages/:messageId](/docs/bots/messages/delete), [GET /v1/bots/:botId/messages/:messageId/context](/docs/bots/messages/context), [POST /v1/bots/:botId/messages/:messageId/reactions](/docs/bots/ui/reaction-add), [DELETE /v1/bots/:botId/messages/:messageId/reactions](/docs/bots/ui/reaction-delete), [PATCH /v1/bots/:botId/commands/:commandId](/docs/bots/commands/update), [DELETE /v1/bots/:botId/commands/:commandId](/docs/bots/commands/delete), [POST /v1/bots/:botId/commands/:commandId/answer](/docs/bots/commands/answer), [GET /v1/bots/:botId/files/:fileId](/docs/bots/files/download). ### FIX-1013-18: даты отбора писем принимают смещения часового пояса **Было** В [GET /v1/mail/messages](/docs/mail/messages/list) даты отбора со смещением без двоеточия или с незакодированным знаком `+` приводили к отказу. Даты с `Z` зависели от версии почтового модуля Битрикс24. **Стало** Параметры `dateFrom` и `dateTo` принимают дату `YYYY-MM-DD` и полную дату-время с `Z` или смещением `+03:00` / `+0300`. Смещение приводится к формату с двоеточием перед отправкой в Битрикс24. Дробная часть секунд может содержать 3 или 6 цифр. **Влияние на интеграторов** Кодируйте `+` в строке запроса как `%2B`. Дату без времени и остальные параметры отбора изменение не затрагивает.