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

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

FIX-1018-1: запоздавшая отмена пробуждения не останавливает готовый сервер

Было

POST /v1/infra/servers/:id/wake с wait=true мог сообщить об ошибке и остановить уже готовый сервер, если его состояние изменилось в конце ожидания. То же касалось автоматического пробуждения спящего сервера перед POST /v1/infra/servers/:id/deploy, POST /v1/infra/servers/:id/exec, POST /v1/infra/servers/:id/upload и GET /v1/infra/servers/:id/logs.

Стало

Если отмена уже не применима к текущему состоянию сервера, она не останавливает его. Готовый сервер в состоянии running с подключённым туннелем и без запрета пробуждения даёт успешный результат. Если готовность подтвердить нельзя, ответ — 502 WAKE_FAILED. Если запуск уже отклонён из-за нехватки мощности, сохраняется 503 WAKE_NO_CAPACITY. Обычный таймаут с возвратом сервера в sleeping по-прежнему даёт 503 WAKE_TIMEOUT.

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

Форма ответа и параметры запросов прежние. После WAKE_FAILED проверьте актуальное состояние через GET /v1/infra/servers/:id перед следующим действием.

FIX-1018-2: Создание отделов списком

Было: POST /v1/humanresources/nodes/batch с action: "create" возвращал ERROR_METHOD_NOT_FOUND для каждого элемента, хотя создание по одному работало.

Стало: создание выполняется через REST 3.0 с отдельным результатом и номером узла для каждого успешного элемента. Ответ остаётся HTTP 200; частичный отказ сохраняет результаты остальных элементов. Каждый элемент требует отдельного обращения к Битрикс24; создания внутри списка идут по очереди, чтобы не конфликтовать на общей структуре. Если исход записи неизвестен, элемент содержит details.outcome: "unknown" и details.retryable: false: проверьте портал перед повторной попыткой. Неполный ответ без номера узла получает WRITE_OUTCOME_UNKNOWN. Изменение списком в эту коррекцию не входит.

NEW-1018-3: статус входа пользователей приложения

Новый метод GET /v1/app-user-signin/servers/{serverId}/status отвечает, работает ли сейчас в приложении на сервере вход пользователей через SDK платформы Вайбкод и какие провайдеры входа в нём включены. Поле state принимает одно из значений: working, not_installed, outdated, unreachable, sleeping, not_public, unsupported_runtime, no_server (последнее — у приложения без сервера, этот метод его не возвращает); список providers непуст только при working. Платформа спрашивает само приложение, только когда сервер запущен и открыт для всех: спящий или закрытый сервер этот вызов не трогает и не будит, а ответ строится по полям сервера и последнему известному результату (lastKnown, checkedAt). Результат проверки кешируется на короткое время, признак fromCache говорит, взят ли ответ из прежней проверки. Доступ и отказы — как у метода настройки: вызывает владелец сервера ключом с правом vibe:infra; ключ, привязанный к приложению, видит только сервер этого приложения. Без права — 403 INFRA_SCOPE_REQUIRED, пока функция не включена для владельца ключа — 404 ROUTE_NOT_FOUND, на чужой сервер или на другой сервер для ключа приложения — 404 SERVER_NOT_FOUND.