Изменения API: 26 августа 2026

← Журнал изменений · Август 2026

FIX-0826-1: socnetGroupId работает на вложенных ресурсах списков рабочих групп

Было

Параметр socnetGroupId учитывался только на самих списках — GET /v1/lists и GET /v1/lists/{iblockId}. На вложенных ресурсах он принимался и молча терялся: GET /v1/lists/{iblockId}/elements, поля, разделы, файлы свойства и все удаления при iblockTypeId=lists_socnet уходили в Битрикс24 без идентификатора группы. Битрикс24 искал инфоблок вне рабочей группы, не находил его и отвечал ошибкой о неверном типе инфоблока — клиент видел 422, хотя группу в запросе указал.

Стало

socnetGroupId доезжает до Битрикс24 со всех эндпоинтов семейства /v1/lists: в строке запроса на чтениях и удалениях, в теле запроса на создании и изменении. Список элементов, полей и разделов списка рабочей группы возвращается так же, как у обычного списка.

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

Менять запросы не нужно. Если обход списков рабочих групп был построен на прямых вызовах lists.* из-за этой ошибки, теперь он собирается на эндпоинтах платформы Вайбкод.

BC-0826-2: exec в galaxy-приложение отвечает CONTAINER_NOT_READY вместо мнимого успеха

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

Было

POST /v1/infra/servers/{id}/exec у galaxy-приложения, контейнер которого ещё не поднят, отвечал 200 и success: true, а внутри отдавал exitCode: 1 и текст движка контейнеров в поле stderr. Команда не выполнялась, но ответ выглядел успешным, и клиенту приходилось разбирать сообщение об ошибке строкой, чтобы понять причину.

Стало

Такой вызов отвечает 502 с кодом CONTAINER_NOT_READY и подсказкой hint, которая ведёт к выкладке приложения. Подробности движка контейнеров наружу больше не возвращаются. Клиентам, которые ожидали 200, нужно обрабатывать CONTAINER_NOT_READY как сигнал сначала выложить приложение и затем повторить команду. Разбор ответа строкой не нужен: причина названа кодом. Если host-agent ещё не поддерживает безопасный container_exec, платформа не запускает legacy-команду и отвечает 502 EXEC_FAILED; после обновления агента вызов можно повторить. Ответы успешных команд на поддерживаемой версии агента не изменились.

FIX-0826-3: 404 для имён методов Битрикс24 указывает на маршрут V1

Было

Запросы GET /v1/catalog.product.list, GET /v1/crm.deal.list, GET /v1/crm.user.list и GET /v1/crm.deal.search возвращали общий 404 ROUTE_NOT_FOUND только с указателем на GET /v1/guide. Агенту приходилось самостоятельно искать замену среди маршрутов V1.

Стало

Эти запросы по-прежнему возвращают 404 ROUTE_NOT_FOUND и не вызывают метод Битрикс24, но теперь error.details содержит причину BITRIX_METHOD_AS_PATH, исходное имя метода, объект suggestedEndpoint с правильными HTTP-методом и путём и объект guide с указателем на GET /v1/guide. Подсказки ведут на GET /v1/catalog-products, GET /v1/deals, GET /v1/users или POST /v1/deals/search.

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

Не формируйте пути V1 из имён методов Битрикс24. При error.details.reason = BITRIX_METHOD_AS_PATH повторите запрос по suggestedEndpoint, а требования к параметрам уточните через guide.

FIX-0826-4: Нейтральное смещение в английском описании createdDate

Было

GET /v1/task-time/fields использовал для createdDate пример смещения, специфичный для одного региона.

Стало

Английское описание использует нейтральное смещение +00:00.

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

Действий не требуется. Изменился только пример в описании поля.

NEW-0826-5: создание приложения из десктопа Коворк/Код — две новые ручки

Приложение платформы Вайбкод теперь создаётся прямо из десктопа, без похода в кабинет за ключом.

GET /v1/cowork/applications/defaults отдаёт всё, что мастеру нужно до первого вопроса человеку: пресеты «какие данные портала нужны приложению», режим доступа, которым аккаунт снабжает новые ключи по умолчанию, остаток квоты ключей и параметры сервера для последующего вызова POST /v1/infra/servers. Ручка только читает и ничего не создаёт. Пресет несёт идентификатор и набор скоупов, но не подписи: платформа отвечает за состав пресета, а формулировку клиент локализует по устойчивому идентификатору. Признак placement имеет три значения, а не два: galaxy-preferred — обычный вердикт аккаунта, которому политика разрешает оба размещения, и в него же понижается galaxy у аккаунта на бесплатном тарифе. Когда создание выключено настройкой платформы, ручка отвечает 200 с полем available: false, а не отказом: мастер прячет пункт меню заранее, вместо того чтобы упереться в отказ после ввода имени.

POST /v1/cowork/applications создаёт личное приложение и чеканит его личный ключ, который возвращается один раз. Сервер при этом не создаётся: у личного приложения его нет по определению, он доращивается публикацией и сам привязывается к карточке. Карточка в ответе несёт тот же набор полей, что витрина приложений, поэтому объект «приложение» у клиента остаётся один. Часть признаков эта ручка не наполняет — закрепление, сохранённые версии исходников и идущую операцию читайте из витрины.

Заголовок Idempotency-Key обязателен. Повтор с тем же телом отвечает 201, заголовком Idempotent-Replayed: true и rawApiKey: null — сырой ключ хранится необратимо и повторно не выдаётся. Потерянный ключ этим же ключом Коворк/Код не перевыпускается — идентификатора выданного ключа в ответе нет, поэтому сохраняйте его сразу, а взамен потерянного создавайте приложение заново с новым значением заголовка. Тот же заголовок с другим телом отвечает 409 IDEMPOTENCY_KEY_BODY_MISMATCH; отпечаток берётся с нормализованного тела, поэтому переставленный порядок полей и другой порядок скоупов повтор не ломают.

Скоупы Битрикс24 обязательны и дефолта не имеют. Выданный ключ несёт права на инфраструктуру и хранилище плюс запрошенные скоупы Битрикс24 и намеренно НЕ несёт прав на ИИ и веб-поиск: приложение, созданное этой ручкой, не расходует кошелёк платформы на ИИ.

Обе ручки требуют скоуп vibe:cowork и активную подписку Коворк/Код. Ключ подписки, выписанный для сторонней агентной программы, к ним не допускается — 403 COWORK_HARNESS_KEY_FORBIDDEN.

FIX-0826-6: график работ отвечает понятной ошибкой, когда не передан обязательный id

Было

GET /v1/workday/schedule без обязательного id уходил в Битрикс24 и возвращал 422 BITRIX_ERROR с текстом Битрикс24 о ненайденном параметре. Ни имени параметра в понятном виде, ни указания на этот метод в ответе не было, а машинное описание метода не объявляло id обязательным, поэтому сгенерированный клиент сам собирал такой вызов.

Стало

Запрос без id отклоняется до обращения к Битрикс24 и возвращает 400 MISSING_REQUIRED_PARAMS с указанием, что нужен идентификатор графика, а не пользователя. В машинном описании метода id объявлен обязательным query-параметром.

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

Запрос с id работает как раньше. Если вызов делался без id, вместо 422 придёт 400 — ответ и раньше был ошибкой, менять рабочие запросы не требуется.

NEW-0826-7: приложению не выдаётся право `vibe:infra` на портале с выключенной инфраструктурой

Было

POST /v1/apps со списком прав, где есть vibe:infra, создавал приложение и его ключ с этим правом независимо от того, включена ли инфраструктура на портале.

POST /v1/apps
{ "title": "My app", "scopes": ["crm", "vibe:infra"] }

HTTP 201
{ "success": true, "data": { "scopes": ["crm", "vibe:infra"] } }

Стало

Если администратор портала выключил работу с серверами, запрос с этим правом отвечает 403 INFRA_DISABLED_FOR_PORTAL, приложение не создаётся.

POST /v1/apps
{ "title": "My app", "scopes": ["crm", "vibe:infra"] }

HTTP 403
{
  "success": false,
  "error": {
    "code": "INFRA_DISABLED_FOR_PORTAL",
    "message": "Infrastructure is disabled on this portal — the vibe:infra scope cannot be granted"
  }
}

Успешный путь не меняется: на портале с включённой инфраструктурой на тот же запрос ответ по-прежнему HTTP 201. Запрос без этого права проходит и на закрытом портале — там право просто не дописывается по умолчанию, отказа не будет.

NEW-0826-8: право `vibe:infra` нельзя добавить приложению через правку его прав

Было

PATCH /v1/apps/:id со списком прав, куда дописано vibe:infra, проставлял это право парным ключам приложения независимо от того, включена ли инфраструктура на портале. Через этот путь ключ получал доступ к серверам там, где создание такого ключа отказом закрыто.

PATCH /v1/apps/{id}
{ "scopes": ["crm", "vibe:infra"] }

HTTP 200
{ "success": true, "data": { "scopes": ["crm", "vibe:infra"] } }

Стало

Если администратор портала выключил работу с серверами, попытка добавить право отвечает 403 INFRA_DISABLED_FOR_PORTAL, права приложения и его ключей не меняются.

PATCH /v1/apps/{id}
{ "scopes": ["crm", "vibe:infra"] }

HTTP 403
{
  "success": false,
  "error": {
    "code": "INFRA_DISABLED_FOR_PORTAL",
    "message": "Infrastructure is disabled on this portal — the vibe:infra scope cannot be granted"
  }
}

Успешный путь не меняется: на портале с включённой инфраструктурой на тот же запрос ответ по-прежнему HTTP 200. Правка приложения, которое это право уже несёт, проходит и на закрытом портале, снятие права разрешено всегда.

NEW-0826-9: управление галактическим сервером закрыто, пока галактики выключены на портале

Было

Флаг галактик проверялся только при создании. Уже созданным галактическим сервером — POST /v1/infra/servers/:id/wake, PATCH /v1/infra/servers/:id/sleep и остальные изменяющие операции — можно было управлять и после того, как администратор портала выключил галактики.

POST /v1/infra/servers/{id}/wake

HTTP 200
{ "success": true }

Стало

Пока галактики на портале выключены, изменяющие операции над таким сервером отвечают 403 GALAXY_DISABLED.

POST /v1/infra/servers/{id}/wake

HTTP 403
{
  "success": false,
  "error": {
    "code": "GALAXY_DISABLED",
    "message": "Galaxy feature is not enabled for this portal"
  }
}

На портале с включёнными галактиками ответ по-прежнему HTTP 200. Чтение (GET), обновление статуса (POST /v1/infra/servers/:id/refresh) и удаление сервера остаются доступными всегда: уйти из пилота и убрать за собой можно и после выключения. Обычных серверов правило не касается.

NEW-0826-10: право `vibe:infra` не выдаётся на портале с выключенной инфраструктурой

Было

POST /v1/keys и PATCH /v1/keys/:id выдавали ключу право vibe:infra независимо от того, включена ли инфраструктура на портале: доступность проверял только интерфейс кабинета.

PATCH /v1/keys/{id}
{ "scopes": ["crm", "vibe:infra"] }

HTTP 200
{ "success": true, "data": { "scopes": ["crm", "vibe:infra"] } }

Стало

Если администратор портала выключил работу с серверами, попытка добавить право отвечает 403 INFRA_DISABLED_FOR_PORTAL.

PATCH /v1/keys/{id}
{ "scopes": ["crm", "vibe:infra"] }

HTTP 403
{
  "success": false,
  "error": {
    "code": "INFRA_DISABLED_FOR_PORTAL",
    "message": "Infrastructure is disabled on this portal — the vibe:infra scope cannot be granted"
  }
}

Успешный путь не меняется: на портале с включённой инфраструктурой на тот же запрос ответ по-прежнему HTTP 200. Правка ключа, который это право уже несёт, продолжает работать и на закрытом портале: гейт считает добавление права, а не его присутствие в теле запроса. Удаление права разрешено всегда. При создании ключа без явной просьбы право просто не дописывается по умолчанию — отказа не будет.

NEW-0826-11: карта требуемых прав в самоописании ключа

GET /v1/me теперь отдаёт в блоке data.api поле scopeRequirements — карту прав ключа. Раньше границу ключа можно было узнать только вызовом: запрос уходил и возвращался отказом 403 SCOPE_DENIED, называющим недостающее право. Список доступных сущностей показывал только то, что открыто, а закрытое просто отсутствовало, и по отсутствию нельзя было отличить «такой сущности нет в продукте» от «она есть, но вашему ключу закрыта».

Поле granted перечисляет права, которые у ключа есть, отдельно по Битрикс24 и по Вайбкод. Поле missing перечисляет недостающие и для каждого показывает, какие сущности и какие адреса оно откроет, а также howToObtain — способ получения: права Битрикс24 закрепляются за ключом при выпуске, поэтому получить их можно только перевыпуском. Списки адресов обрезаны на пяти элементах, остаток назван в unlocksRemaining рядом с признаком truncated. Поле unobtainable перечисляет права, которые личный ключ-вебхук нести не может в принципе. Поле aliases показывает написания, которые Битрикс24 считает одним правом.

Поле coverage объявляет полноту самой карты: entities всегда complete, а paths пока partial — часть адресов ещё не имеет машинного вердикта, поэтому списки путей занижают. Отсутствие адреса в unlocks не доказывает, что адрес не требует прав: если вызов всё-таки отвечает отказом, верьте отказу, а не карте. Права, которые платформа выдаёт сама и пользователь получить не может, попадают в unobtainable, а не в missing с невыполнимым советом.

Карта описывает только проверку прав на стороне платформы, о чём предупреждает _note. Она не обещает, что вызов пройдёт: право, выданное в кабинете уже после выпуска ключа, попадёт в карту, но Битрикс24 его не признает и ответит BITRIX_ACCESS_DENIED. Отказы по виду ключа, владению, режиму только для чтения, заморозке и тарифу — отдельные оси, в карте они не описаны.

Отбивки не изменились ни кодом, ни текстом: 403 SCOPE_DENIED по-прежнему называет недостающее право. Добавлена предварительная проверка, а не замена отбивки.

FIX-0826-12: сортировка комментариев задачи в скобочной форме `?sort[поле]=направление`

Было

GET /v1/tasks/{taskId}/comments?sort[id]=desc отвечал 500 INTERNAL_ERROR. Скобочную форму сортировки принимают /v1/tasks и /v1/deals, а плоская форма того же запроса — ?sort=id:desc — работала и здесь, поэтому отказ выглядел случайным. Ошибку давала любая скобочная сортировка, включая несортируемое поле: ?sort[createdAt]=desc тоже отвечал 500, тогда как плоский ?sort=createdAt возвращал понятный 400 INVALID_SORT_FIELD с перечнем допустимых полей.

Стало

Скобочная форма разбирается так же, как плоская, и проходит ту же проверку имени поля. ?sort[id]=desc сортирует по ID и отвечает 200; плоская форма ?sort=id:desc не меняется — её ответ остаётся HTTP 200. Несортируемое поле в скобках отвечает 400 INVALID_SORT_FIELD с тем же перечнем полей, что и плоская форма, и текст ошибки называет поле — Unsupported sort 'createdAt:desc'. Сортировка в форме, которую нельзя прочитать однозначно (повторный параметр, смешение плоской и скобочной форм, вложенные или повреждённые скобки, массив либо больше одного двоеточия), тоже отвечает 400, а не молча переосмысливается или теряется. Такой же скобочный sort на списке пунктов чек-листа задачи теперь отвечает контролируемым 400, а не 500. 500 этот параметр больше не даёт ни в одной форме.

FIX-0826-13: пробуждение приложения на неисправном Galaxy-хосте завершается явной ошибкой

Было

Запросы POST /v1/infra/servers/:id/start и POST /v1/infra/servers/:id/wake для Galaxy-приложения могли выглядеть успешными, хотя гостевая ОС общего хоста уже была признана незагружаемой. Клиент продолжал ждать запуск, который не мог завершиться.

Стало

Для такого Galaxy-приложения оба запроса возвращают HTTP 422 с кодом GUEST_NOT_BOOTING. Клиент может сразу прекратить ожидание и предложить заменить неисправный хост.

FIX-0826-14: отказ Битрикс24 на выписке ключа больше не отдаёт внутренний текст вендора

Было

Когда Битрикс24 отказывал в регистрации на выписке ключа или приложения, в поле error.message уезжала его внутренняя формулировка как есть — например Cannot register webhook: Failed to register webhook in portal. Текст всегда английский, не описан в документации и мог измениться на стороне Битрикс24 в любой момент. Отдельная семья таких отказов (регистрация входящего вебхука) вдобавок отдавала код Битрикс24 напрямую, вместо кода платформы Вайбкод.

Стало

error.message содержит текст платформы Вайбкод, а подробности ответа Битрикс24 остаются в журналах. Отказ регистрации вебхука классифицируется наравне с отказом регистрации приложения и отдаёт REST_REGISTRATION_FAILED. Ответ дополнен полем error.details.incidentCode — шестизначный код обращения, по которому поддержка находит запись в журнале. HTTP-статусы и коды ошибок прежние, клиенту менять ничего не нужно.