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

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

#Остановить сервер

POST /v1/infra/servers/:id/stop

Штатная остановка работающего сервера. Виртуальная машина останавливается у провайдера, статус меняется на sleeping, открытая биллинг-транзакция по рабочему периоду закрывается, открывается транзакция по сонному периоду (тариф sleep существенно ниже). Работает для любого режима — и BLACKHOLE, и OPEN. Сервер можно снова запустить через `POST /start` или разбудить автоматически обращением к субдомену.

#Параметры

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

#Примеры

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

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

#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/stop

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

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

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

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

#Поля ответа

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

{ "success": true }

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

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

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

404 — сервера с таким id нет (удалён или принадлежит другому API-ключу):

{
  "success": false,
  "error": {
    "code": "SERVER_NOT_FOUND",
    "message": "Server not found"
  }
}

#Ошибки

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

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

• Почему sleeping, а не stopped. Это терминология Infrastructure API: остановленный сервер называется «спящим», потому что биллинг для него идёт по отдельному тарифу sleepPriceMonthly (см. тарифы провайдера) — ниже, чем рабочий. Значение stopped в v1-ответах не встречается.
• /stop сбрасывает preventWake (автоматический флаг, блокирующий пробуждение) — после остановки сервер снова можно пробудить автоматически обращением к субдомену или через `/wake`.
• Для BLACKHOLE есть альтернатива — `/sleep-now`. Функционально результат идентичный. /sleep-now используется из UI-кнопки «Усыпить» и явно помечен как BH-специфический. /stop — универсальный для любого режима.

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

• Запустить сервер — POST /v1/infra/servers/:id/start.
• Немедленно усыпить — синоним для BLACKHOLE.
• Настроить авто-сон — чтобы сервер засыпал сам через N минут простоя.
• Удалить сервер — полное удаление виртуальной машины.