#Перезагрузить сервер

POST /v1/infra/servers/:id/reboot

Перезагружает работающий сервер у облачного провайдера. Во время перезагрузки сервер переходит в provisioning и возвращается в running через 30–90 секунд. Операция атомарная: внутренний guard на уровне базы предотвращает гонки, если одновременно пришло несколько вызовов. Если провайдер не поддерживает перезагрузку — возвращается 501 и статус откатывается на running.

#Параметры

Тело запроса пустое.

#Примеры

#curl — личный ключ

curl -X POST -H "X-Api-Key: YOUR_API_KEY" \
  https://vibecode.bitrix24.tech/v1/infra/servers/SERVER_ID/reboot

#curl — OAuth-приложение

curl -X POST -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  https://vibecode.bitrix24.tech/v1/infra/servers/SERVER_ID/reboot

#JavaScript — личный ключ

await fetch(
  `https://vibecode.bitrix24.tech/v1/infra/servers/${serverId}/reboot`,
  { method: 'POST', headers: { 'X-Api-Key': 'YOUR_API_KEY' } }
)

// Опрос готовности после перезагрузки
while (true) {
  await new Promise(r => setTimeout(r, 5000))
  const res = await fetch(
    `https://vibecode.bitrix24.tech/v1/infra/servers/${serverId}`,
    { headers: { 'X-Api-Key': 'YOUR_API_KEY' } }
  )
  const { data } = await res.json()
  if (data.status === 'running' && data.blackholeStatus === 'CONNECTED') break
}

#JavaScript — OAuth-приложение

await fetch(
  `https://vibecode.bitrix24.tech/v1/infra/servers/${serverId}/reboot`,
  {
    method: 'POST',
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
    },
  }
)

#Поля ответа

#Пример ответа

{ "success": true }

#Пример ответа при ошибке

422 — сервер существует, но не в статусе running. В ответе — текущее состояние и доступные действия:

{
  "success": false,
  "error": {
    "code": "SERVER_WRONG_STATE",
    "message": "Server is SLEEPING; /reboot requires RUNNING.",
    "userMessage": "Server is currently SLEEPING. Reboot only applies to a RUNNING server.",
    "currentState": { "status": "SLEEPING", "blackholeStatus": "DISCONNECTED", "hasExternalId": true },
    "availableActions": ["wake", "start", "repair", "delete"]
  }
}

409 — статус сервера изменился во время операции (гонка):

{
  "success": false,
  "error": {
    "code": "CONFLICT",
    "message": "Server state changed during operation"
  }
}

#Ошибки

Полный список общих ошибок API — Ошибки.

#Известные особенности

• Атомарный переход running → provisioning. База обновляется одним updateMany с условием status = 'RUNNING'. Если в тот же момент прилетел ещё один /reboot или /stop, второй вызов получит 409 CONFLICT.
• Автоматический откат при ошибке провайдера. Если adapter.rebootServer() кинул исключение, запись возвращается к статусу running — чтобы клиент не остался с «зависшим» provisioning.
• Для перезапуска только приложения (без перезагрузки виртуальной машины) используйте `POST /exec` с командой systemctl restart app — это в десятки раз быстрее и не прерывает туннель.
• После перезагрузки ждите оба поля. Чтобы сервер был готов к работе, нужны одновременно status: "running" и blackholeStatus: "CONNECTED" — туннель переподключается после старта виртуальной машины.

#Смотрите также

• Запустить сервер — POST /v1/infra/servers/:id/start.
• Остановить сервер — POST /v1/infra/servers/:id/stop.
• Восстановить туннель — если туннель не восстанавливается после перезагрузки.
• Выполнить команду — перезапуск приложения без перезагрузки виртуальной машины.

#Запустить сервер

POST /v1/infra/servers/:id/start

Поднимает сервер из состояний sleeping, error или provisioning. Для sleeping виртуальная машина снова запускается у провайдера и возвращается к статусу running по мере готовности — вызов возвращает ответ сразу, не дожидаясь фактической готовности. Её нужно отслеживать опросом `GET /v1/infra/servers/:id`. Для error с подключённым туннелем (blackholeStatus: "CONNECTED") сервер сразу переводится в running без обращения к провайдеру. Для provisioning делается повторная попытка старта без сброса таймера ожидания. Для running сервера вызов возвращает 404.

#Параметры

Тело запроса пустое.

#Примеры

#curl — личный ключ

curl -X POST -H "X-Api-Key: YOUR_API_KEY" \
  https://vibecode.bitrix24.tech/v1/infra/servers/SERVER_ID/start

#curl — OAuth-приложение

curl -X POST -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  https://vibecode.bitrix24.tech/v1/infra/servers/SERVER_ID/start

#JavaScript — личный ключ

await fetch(
  `https://vibecode.bitrix24.tech/v1/infra/servers/${serverId}/start`,
  { method: 'POST', headers: { 'X-Api-Key': 'YOUR_API_KEY' } }
)
// Ждать готовности — опрашивать GET /v1/infra/servers/:id

#JavaScript — OAuth-приложение

await fetch(
  `https://vibecode.bitrix24.tech/v1/infra/servers/${serverId}/start`,
  {
    method: 'POST',
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
    },
  }
)

#Поля ответа

#Пример ответа

{ "success": true }

#Пример ответа при ошибке

404 — сервер в статусе running/deleted либо чужой:

{
  "success": false,
  "error": {
    "code": "NOT_FOUND",
    "message": "Sleeping, error, or provisioning server not found"
  }
}

#Ошибки

Полный список общих ошибок API — Ошибки.

#Известные особенности

• Блокирующий вариант. Если клиенту нужна полная готовность сервера перед следующим шагом — используйте `POST /wake?wait=true` вместо /start. Он ждёт status: "running" + blackholeStatus: "CONNECTED" до ~6.5 минут.
• Ручной /start обходит preventWake. В отличие от автоматического пробуждения при обращении к субдомену, явный POST /start снимает флаг preventWake и запускает сервер даже если он был заблокирован. Биллинговые блокировки (ACCOUNT_FROZEN) обходятся отдельным пополнением, не через /start.
• Для running возвращает 404, не 409. Сознательный выбор: сервер уже в нужном состоянии, делать нечего. Для перезагрузки — `POST /reboot`.

#Смотрите также

• Остановить сервер — POST /v1/infra/servers/:id/stop.
• Разбудить сервер (с `?wait=true`) — блокирующий вариант с ожиданием готовности.
• Немедленно усыпить — обратная операция.
• Обновить статус — принудительно опросить провайдера после старта.
• Получить сервер — опрос готовности.