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

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

BC-1013-1: Адрес приложения вне платформы: только https, не ключом приложения или сервера

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

Было

POST /v1/apps, PATCH /v1/apps/{id} и POST /v1/apps/{id}/publish принимали в appUrl любой адрес http:// или https://. Опубликовать приложение с адресом вне платформы мог любой ключ, которому разрешено менять приложение.

Стало

Адрес вне платформы принимается только публичный https://, иначе ответ 400 APP_URL_UNSAFE. Опубликовать приложение с адресом, который не обслуживает действующий сервер этого аккаунта на платформе (внешний хост или домен, чей сервер удалён), или перевести на такой адрес опубликованное приложение можно из кабинета платформы Вайбкод или личным ключом. Ключ приложения, ключ 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 для отозванного ключа 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 отвечает 422: такой сервер нужно пересоздать или восстановить из бэкапа, если он есть. Если платформа не смогла попасть на сервер уже в ходе ремонта, GET /v1/infra/servers/{id}/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; завершение видно в списке. В информации о базе показываются возможность создания копий и последняя готовая копия файла по умолчанию. Ключи только для чтения могут просматривать копии; создание требует права записи. Как создавать копии.

NEW-1013-7: Длительные команды с устойчивым результатом

Длительные команды: POST /v1/infra/servers/:id/exec?async=true возвращает 202 и operationId. Обрыв ожидания не теряет результат команды. По существующему GET /v1/infra/operations/:operationId читаются исход и сохранённые 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 с wait=true отвечает 503 с кодом WAKE_NO_CAPACITY. Так же завершается запуск такого спящего сервера при деплое и POST /v1/infra/servers/{id}/start для такого сервера в статусе error. Вызовы без ожидания, то есть /wake без wait=true и /start для спящего сервера, отвечают как раньше, а сервер вскоре возвращается в статус sleeping со значением WAKE_NO_CAPACITY в поле provisionErrorCode ответа GET /v1/infra/servers/{id}. Данные сервера сохранены. Автоматические попытки запуска такого сервера приостанавливаются на десять минут, и в это время /wake сразу отвечает 503 WAKE_NO_CAPACITY. Сервер вида GALAXY_APP размещён на общей машине, и его касается только пауза этой машины: пока она не истекла, /wake и /start приложения сразу отвечают 503 WAKE_NO_CAPACITY. Остальные ответы и поля приложения не меняются. Повторите запрос позже. Существующие запросы работают как раньше.

BC-1013-9: Фильтр вариаций по датам отклоняется

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

Было

GET /v1/catalog-offers, POST /v1/catalog-offers/search, POST /v1/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, POST /v1/catalog-offers/search, POST /v1/catalog-offers/aggregate, прежний GET /v1/catalog-offers/aggregate, POST /v1/{entity}/batch, POST /v1/batch.

FIX-1013-10: непрочитанные тариф и подписка на создании сервера отвечают только 403

Было

POST /v1/infra/servers в части случаев отвечал на 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 возвращал только статические поля с предупреждением 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 для несуществующего или удалённого графика отвечал 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.

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

Правильный запрос менять не нужно. Проверяйте ошибки каждого подвызова. Подробнее — Пакетные вызовы.

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, PATCH /v1/bots/:botId/messages/:messageId, DELETE /v1/bots/:botId/messages/:messageId, GET /v1/bots/:botId/messages/:messageId/context, POST /v1/bots/:botId/messages/:messageId/reactions, DELETE /v1/bots/:botId/messages/:messageId/reactions, PATCH /v1/bots/:botId/commands/:commandId, DELETE /v1/bots/:botId/commands/:commandId, POST /v1/bots/:botId/commands/:commandId/answer, GET /v1/bots/:botId/files/:fileId.

FIX-1013-18: даты отбора писем принимают смещения часового пояса

Было

В GET /v1/mail/messages даты отбора со смещением без двоеточия или с незакодированным знаком + приводили к отказу. Даты с Z зависели от версии почтового модуля Битрикс24.

Стало

Параметры dateFrom и dateTo принимают дату YYYY-MM-DD и полную дату-время с Z или смещением +03:00 / +0300. Смещение приводится к формату с двоеточием перед отправкой в Битрикс24. Дробная часть секунд может содержать 3 или 6 цифр.

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

Кодируйте + в строке запроса как %2B. Дату без времени и остальные параметры отбора изменение не затрагивает.