Lifecycle

Actions on an already-created server: start and stop, reboot, auto-sleep and immediate sleep, wake, forced status refresh, and tunnel repair via the serial console. All endpoints act 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 readiness 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, which does not fire on every request to the subdomain, 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 a running server it returns 422 SERVER_WRONG_STATE. The server is already running — there is no need to start it again. For a reboot — POST /reboot.
• The three 422 codes on this route mean different things. SERVER_WRONG_STATE is a transient state and retrying makes sense. GUEST_NOT_BOOTING is terminal: handle it as "recreate the server", not as a temporary error, otherwise a scheduled start retries forever. AGENT_NEVER_CONNECTED is neither terminal nor transient: retrying the start will never help, but repair fixes it. A client that restarts failed servers on a schedule must tell the three apart — otherwise it waits for nothing on the first, spins forever on the second, and erases its own diagnosis on the third.

Galaxy apps (`kind=GALAXY_APP`)

/start on a sleeping Galaxy app brings it up through the host, the same way /wake does. One difference from a standalone virtual machine matters for the client: the host preventWake flag blocks /start, and here the call does not clear that block.

The full map of an app's lifecycle operations is on the Galaxy app page.

See also

• Galaxy app
• Stop the server
• Wake the server (with ?wait=true)
• Sleep now
• Refresh status
• Get a server