#Reboot server

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

Reboots a running server at the cloud provider. During the reboot the server moves to provisioning, the tunnel is briefly dropped — blackholeStatus becomes DISCONNECTED — and reconnects after the virtual machine starts. The operation is atomic: an internal database-level guard prevents races if several calls arrive at once. If the provider does not support reboot, it returns 501 and the status is rolled back to running.

#Parameters

The request body is empty.

#Examples

#curl — personal key

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

#curl — OAuth application

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

#JavaScript — personal key

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

// Poll readiness after the reboot
while (true) {
  await new Promise(r => setTimeout(r, 5000))
  const res = await fetch(
    `https://vibecode.bitrix24.com/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 application

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

#Response fields

#Response example

{ "success": true }

#Error response example

422 — the server exists but is not in running status. The response carries the current state and the actions available now:

{
  "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 — the server status changed during the operation (race):

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

#Errors

The full list of common API errors — Errors.

#Known specifics

• Atomic transition running → provisioning. The database is updated with a single updateMany conditioned on status = 'RUNNING'. If another /reboot or /stop arrives at the same moment, the second call gets 409 CONFLICT.
• Automatic rollback on a provider error. If adapter.rebootServer() throws an exception, the record is reverted to running status — so the client is not left with a "stuck" provisioning.
• To restart only the application (without rebooting the virtual machine) use POST /exec with the command systemctl restart app — it is dozens of times faster and does not break the tunnel.
• After a reboot, wait for both fields. For the server to be ready, you need both status: "running" and blackholeStatus: "CONNECTED" at the same time — the tunnel reconnects after the virtual machine starts.

#See also

• Start server — POST /v1/infra/servers/:id/start.
• Stop server — POST /v1/infra/servers/:id/stop.
• Repair tunnel — if the tunnel does not recover after a reboot.
• Run a command — restart the application without rebooting the virtual machine.

#Start the server

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

Brings a server up from the sleeping, error, or provisioning states. For sleeping, the virtual machine is started again at the provider and returns to running status as it becomes ready — the call returns a response immediately, without waiting for actual readiness; track it by polling GET /v1/infra/servers/:id. For error with a connected tunnel (blackholeStatus: "CONNECTED"), the server is moved straight to running without contacting the provider. For provisioning, the start is retried without resetting the wait timer. If the server is not in one of these states — for example, already running — the call returns 422 SERVER_WRONG_STATE with the current state (currentState) and the list of available actions (availableActions).

#Parameters

The request body is empty.

#Examples

#curl — personal key

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

#curl — OAuth application

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

#JavaScript — personal key

await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/start`,
  { method: 'POST', headers: { 'X-Api-Key': 'YOUR_API_KEY' } }
)
// Wait for readiness — poll GET /v1/infra/servers/:id

#JavaScript — OAuth application

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

#Response fields

#Response example

{ "success": true }

#Error response example

422 — the server exists but is not in sleeping/error/provisioning status, for example already running. The response carries the current state and the actions available now:

{
  "success": false,
  "error": {
    "code": "SERVER_WRONG_STATE",
    "message": "Server is RUNNING; /start requires one of SLEEPING, ERROR, PROVISIONING.",
    "userMessage": "Server is currently RUNNING. Start only applies to SLEEPING, ERROR, or PROVISIONING servers.",
    "currentState": { "status": "RUNNING", "blackholeStatus": "CONNECTED", "hasExternalId": true },
    "availableActions": ["reboot", "sleep-now", "delete"]
  }
}

#Errors

Full list of common API errors — Errors.

#Known specifics

• Blocking variant. If the client needs the server fully ready before the next step — use POST /wake?wait=true instead of /start. It waits for status: "running" + blackholeStatus: "CONNECTED" for up to ~6.5 minutes.
• Manual /start bypasses preventWake. Unlike automatic wake on subdomain access, an explicit POST /start clears the preventWake flag and starts the server even if it was blocked. Billing locks (ACCOUNT_FROZEN) are cleared by a separate top-up, not via /start.
• For running it returns 422 SERVER_WRONG_STATE. The server is already running — no repeat start is needed. For a reboot — POST /reboot.

#See also

• Stop the server — POST /v1/infra/servers/:id/stop.
• Wake the server (with ?wait=true) — blocking variant that waits for readiness.
• Sleep now — the reverse operation.
• Refresh status — force a provider poll after start.
• Get the server — poll for readiness.