DeluxHostAPI Reference
Services & monitoring

Get server resource usage

GET
/v1/services/{id}/usage

limitBytes: 0 means unmetered. cpuPercent, memUsedMb and disks come from the guest agent and are null or empty without it.

Authorization

apiToken services:read
headerAuthorizationBearer <token>

A personal API token: Authorization: Bearer dh_live_…. See Authentication for scopes.

Scope: services:read

Path Parameters

id*integer

The service id, as returned by GET /v1/services.

Response Body

Usage.

application/json
  1. response
cpuPercent*number|null
memUsedMb*integer|null
memTotalMb*integer|null
disks*array<>
traffic*|null
curl -X GET 'https://api.deluxhost.net/v1/services/0/usage' \  -H "Authorization: Bearer $DELUXHOST_TOKEN"
Example Response
{  "cpuPercent": 0,  "memUsedMb": 0,  "memTotalMb": 0,  "disks": [    {      "mount": "string",      "totalGb": 0,      "usedGb": 0    }  ],  "traffic": {    "rxBytes": 0,    "txBytes": 0,    "totalBytes": 0,    "limitBytes": 0,    "periodStart": "string",    "periodEnd": "string"  }}

Get server status GET

Read from the panel on every call, so it is slower than the service itself and can fail on its own. `powerState` is `running`, `stopped` or `unknown` — the last means we could not read it (usually an unreachable hypervisor), not that the server is off. Answers for **VirtFusion and TenantOS services alike**: same question, same shape, different source. `building` is only ever true on VirtFusion; `cpuModel` is only ever set on TenantOS. Shared hosting is not a machine and lives at `/v1/services/{id}/hosting`. A suspended service answers 400 here while still appearing in `GET /v1/services`.

Change server power state POST

VirtFusion supports boot, restart, shutdown and poweroff. TenantOS supports boot, restart and poweroff; graceful shutdown is refused rather than mapped to a hard power cut. **409 is the normal answer** a few seconds after any other operation, including a console being closed: the panel queues one task per server. Back off and retry; it is not a failure. **No idempotency key in v1.** `boot` and `shutdown` are safe to repeat; a retried `restart` reboots the machine a second time, so a client that retries automatically should read `powerState` first.