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

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

BC-1019-1: Добавление доступа к хранилищу требует личного ключа

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

Было

Правка scopes могла добавить vibe:storage ключу приложения или ключу неизвестного происхождения, открывая доступ к файлам владельца.

Стало

Ручное добавление через PATCH /v1/keys/:id, управляющий ключ или MCP отклоняется с 403 KEY_STORAGE_SCOPE_REQUIRES_PERSONAL_KEY. То же ограничение действует при изменении прав парного ключа через PATCH /v1/apps/:id. Уже выданное право можно сохранить без изменения или снять; переименование и другие правки разрешены. Конкурентная операция может вернуть 409 KEY_OPERATION_IN_PROGRESS.

При POST /v1/keys и POST /v1/apps ключ приложения или ключ неизвестного происхождения не получает хранилище по умолчанию; явный запрос этого права возвращает тот же 403 до создания ключа или приложения. Выдача через OAuth для партнёрских приложений сохраняет отказ 400 CONNECT_STORAGE_SCOPE_UNAVAILABLE. Системная выдача Коворка и замена его ключей сохраняют доступ к хранилищу; ранее снятое право не возвращается. Ключи партнёрских приложений не получают хранилище при замене.

Что делать интеграторам

Создайте новый личный ключ с правом хранилища. При 409 KEY_OPERATION_IN_PROGRESS перечитайте ключ или приложение и повторите операцию с текущим набором прав.

FIX-1019-2: Connect отзывает ключ предъявленного устройства Коворка

Было

POST /v1/connect/revoke с client_id=cowork-desktop и ключом этого клиента отвечал HTTP 200, но оставлял ключ активным.

Стало

Ответ POST /v1/connect/revoke остаётся HTTP 200. Предъявленный ключ устройства отзывается, дальнейшие запросы с ним отклоняются. Ключи других устройств остаются активными. Неизвестные, чужие и уже отозванные токены по-прежнему дают HTTP 200 без раскрытия состояния ключа. DELETE /v1/cowork/key также остаётся доступен для отзыва собственного ключа устройства.

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

Существующий запрос отзыва теперь отключает предъявленное устройство; для дальнейшей работы на нём потребуется войти снова. Формат запроса и ответа не меняется.

FIX-1019-3: ссылки на собственное хранилище распознаются при деплое

При создании приложения и деплое через source.url ссылки на бакет платформы распознаются как в форме отдельного хоста бакета, так и с именем бакета в пути. Версия исходников связывается с деплоем в обеих формах. Если для вашего аккаунта доступна выкладка на общем сервере по ссылке, ссылки на другие бакеты не допускаются: сначала сохраните архив как версию исходников и используйте source.versionId.

NEW-1019-4: Явный ранний отказ при повторении JSON

В POST /v1/chat/completions доступна опция repetition_guard: "off" | "abort". Отсутствие опции или "off" сохраняет прежнее поведение. Явный "abort" останавливает запрос при эвристически обнаруженном повторе JSON до завершения генерации. Нужны response_format с типом json_object или json_schema, отсутствие объявленных инструментов и модель с поддержкой потока даже для синхронного ответа. Несовместимый запрос получает 400 invalid_request до обращения к модели. При обнаружении повтора синхронный клиент получает 422 reasoning_repetition, а потоковый — одно событие error и один data: [DONE] при HTTP 200. Частичный ответ нужно отбросить. Законные повторяющиеся массивы могут вызвать ложный отказ, поэтому для них оставляйте опцию выключенной. Условия и пример SDK — в документации JSON-ответа.

FIX-1019-5: запуск сервера из ошибки, не дождавшийся готовности, возвращает его в ошибку

Было

POST /v1/infra/servers/{id}/start для сервера в статусе error переводил его в provisioning. Если машина так и не поднималась, по истечении ожидания сервер получал статус sleeping, причина ошибки пропадала из ответа, а списания за спящий сервер возобновлялись.

Стало

Несостоявшийся запуск из error возвращает сервер в error с прежней причиной, списания не возобновляются. Запуск из sleeping по истечении ожидания по-прежнему возвращает сервер в sleeping.

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

Действий не требуется. После неудачного запуска сервера в статусе error опрос GET /v1/infra/servers/{id} покажет error, а не sleeping.

NEW-1019-6: выпуск приложения галактики на отдельный сервер сохраняет свой домен

Создание отдельного сервера взамен приложения галактики — POST /v1/infra/servers с placement: "dedicated" и graduateFrom — сохраняет свой домен приложения: имя переезжает на созданный сервер вместе с подтверждением, записи DNS и TXT-токен остаются прежними, привязывать домен заново не нужно.

Ответ 201 этого вызова получил необязательное поле верхнего уровня warningCodes — машинные коды к строкам warnings, чтобы ветвиться без разбора текста. Поле приходит только тогда, когда есть что сообщить, и набор кодов открытый: незнакомый код нужно пропускать, а не считать ошибкой.

Первый такой код — GRADUATION_DOMAIN_REGISTRY_PENDING: домен уже закреплён за новым сервером, но пока не открывается. Соседняя строка warnings называет имя и единственный вызов, который это доигрывает — POST /v1/infra/servers/{id}/domain/verify на новом сервере. Записи DNS при этом менять не нужно.

Свой домен приложения пока доступен только порталам пилотной программы, поэтому всё описанное выше действует только на них. На остальных порталах у приложения галактики своего домена нет, и ответ этого вызова не меняется.

NEW-1019-7: Восстановление регистрации бота после ответа без ID

Для регистрации бота через POST /v1/bots с режимом webhook API Вайбкод теперь подтверждает сохранённую запись URL по ответу портала и возвращает data.botId, когда остальные свойства бота проверены. Если прежняя регистрация осталась в ожидании подтверждения, вызовите POST /v1/bots/registrations/:code/recover с тем же ключом и кодом. Успех возвращает data.botId; действие проверяет уже созданного бота и не регистрирует нового. При 409 повторите действие после Retry-After или обратитесь в поддержку, если подтверждение не завершается.

NEW-1019-8: ссылки на новые страницы открытых линий в `GET /v1/guide`

Объект openLines.docs в ответе GET /v1/guide получил семь новых ссылок: crmMembersCreate, crmMembersDelete, crmMessages, crmLead, sessionsSearch, sessionsIntercept и sessionsJoin. Они ведут на отдельные страницы методов: добавить и удалить сотрудника CRM-чата, отправить сообщение клиенту, создать лид из обращения, найти сессии, перехватить диалог и войти в диалог. Прежние ключи openLines.docs остались на месте, ответ по-прежнему HTTP 200.

FIX-1019-9: Подсказка при повторном использовании сервера объясняет создание второго приложения

Было

При повторном использовании сервера ответ POST /v1/infra/servers сообщал об уже привязанном сервере, но не объяснял, как создать второе приложение.

Стало

Поле hint объясняет: для второго приложения создайте отдельную карточку приложения с собственным API-ключом и используйте этот ключ для нового приложения.

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

Существующие запросы менять не нужно. Правило повторного использования сервера и поля ответа сохранены.

NEW-1019-10: адреса переходов из списка коннекторов Коворка

GET /v1/connectors для Коворка возвращает manageUrl для управления подключениями, addUrl для каталога и addOwnUrl: null; при null используется addUrl. Адрес карточки items[].webUrl изменен на /extensions/connectors/<slug>. Адреса абсолютные и открываются в системном браузере. Ответ для ключей приложения не меняется.

FIX-1019-11: первая выкладка Node.js 20 на новом сервере не ждёт системных обновлений

Было

POST /v1/infra/servers/:id/deploy с runtime из семейства node20 устанавливал на сервер пакет unzip. На только что созданном сервере в это время шли фоновые обновления операционной системы, и выкладка заканчивалась ошибкой RUNTIME_PREREQUISITES_LOCK_TIMEOUT или RUNTIME_PREREQUISITES_TIMEOUT. То же ожидание случалось перед распаковкой .zip в выкладке и в POST /v1/infra/servers/:id/upload.

Стало

Рантайм node20 больше не требует unzip: архивы .zip распаковывает агент сервера. На сервере с актуальным агентом выкладка и загрузка .zip не устанавливают unzip и не ждут фоновых обновлений. Коды UNZIP_PREFLIGHT_FAILED и связанный с этим шагом EXEC_BUSY остаются только для серверов со старым агентом.

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

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