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

[← Журнал изменений](/docs/changelog) · [Октябрь 2026](/docs/changelog/2026-10)

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

**Было**

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

**Стало**

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

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

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

### 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`.