#Lifecycle

Actions on an already-created server: start and stop, reboot, auto-sleep and immediate sleep, wake, forced status refresh, tunnel repair via serial console. All endpoints are actions on a specific :id, and most return { "success": true }.

Scope: vibe:infra

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