DeluxHostAPI Reference
Services & monitoring

Get service metrics

GET
/v1/services/{id}/metrics

What the server has been doing, from samples taken about every ten minutes. /usage answers the same question about right now with a live call to the panel; this one never leaves our process, which is why it can be polled and /usage cannot.

rxDeltaBytes and txDeltaBytes are traffic in that interval, not since the beginning: the panel's counters are cumulative and reset monthly. They are null on the first point, which has no previous sample to subtract.

An empty points is a normal answer — a service provisioned ten minutes ago has no samples, and one that is not a VirtFusion server never will.

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.

Query Parameters

hours?integer

How far back to go.

Range1 <= value <= 168
Default24

Response Body

The samples, oldest first.

application/json
  1. response
points*array<>
curl -X GET 'https://api.deluxhost.net/v1/services/0/metrics' \  -H "Authorization: Bearer $DELUXHOST_TOKEN"
Example Response
{  "points": [    {      "ts": "2019-08-24T14:15:22Z",      "cpuPercent": 0,      "memPercent": 0,      "rxDeltaBytes": 0,      "txDeltaBytes": 0    }  ]}

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.

List server tasks GET

What the panel has done to this server, newest first: the way to find out whether the action `POST /v1/services/{id}/power` accepted actually finished. Match the `taskId` that call returned against `id` here, and read `status`. A task is `running` until the panel finishes it, then `completed` or `failed`. Why a task failed is not published — the upstream message is not ours to hand out. Staff-side rows (an operator suspending the service) are not in this feed.