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

[← Журнал изменений](/docs/changelog) · [Август 2026](/docs/changelog/2026-08)

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

**Было**

Параметр `socnetGroupId` учитывался только на самих списках — [GET /v1/lists](/docs/lists/lists/list) и [GET /v1/lists/{iblockId}](/docs/lists/lists/get). На вложенных ресурсах он принимался и молча терялся: [GET /v1/lists/{iblockId}/elements](/docs/lists/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](/docs/keys-auth/guide). Подсказки ведут на [GET /v1/catalog-products](/docs/entities/catalog-products), [GET /v1/deals](/docs/entities/deals), [GET /v1/users](/docs/entities/users) или [POST /v1/deals/search](/docs/entities/deals/search).

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

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

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

**Было**

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

**Стало**

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

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

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

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

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

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

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

Заголовок `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](/docs/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`, создавал приложение и его
ключ с этим правом независимо от того, включена ли инфраструктура на портале.

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

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

**Стало**

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

```json
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`, проставлял это
право парным ключам приложения независимо от того, включена ли инфраструктура на
портале. Через этот путь ключ получал доступ к серверам там, где создание такого
ключа отказом закрыто.

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

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

**Стало**

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

```json
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`
и остальные изменяющие операции — можно было управлять и после того, как
администратор портала выключил галактики.

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

HTTP 200
{ "success": true }
```

**Стало**

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

```json
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`
независимо от того, включена ли инфраструктура на портале: доступность
проверял только интерфейс кабинета.

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

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

**Стало**

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

```json
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](/docs/keys-auth/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-статусы и коды ошибок прежние, клиенту менять
ничего не нужно.