API Documentation

Compute automation

List clusters and nodes, run lifecycle actions, and manage images and SSH keys. Capacity expansion is ordered through the networking guide; nodes are reserved by term.

Product model. GPU capacity is reserved by term (node or rack), not created on demand as hourly VMs. Use this guide for inventory and lifecycle; use orders to add capacity. See also AI Infrastructure.

Clusters

Returns the clusters provisioned to your account, with fabric and facility context.

GET /v1/clusters
{
  "data": [
    {
      "id": "clu_4e91b2a0",
      "name": "train-a",
      "facility": "DFW",
      "state": "active",
      "gpu_model": "H100-SXM",
      "node_count": 16,
      "fabric": "rdma",
      "activated_at": "YYYY-MM-DDTHH:MM:SSZ"
    }
  ],
  "meta": { "count": 1 }
}

Nodes

Lists nodes in a cluster, or a single node by id.

GET /v1/clusters/clu_4e91b2a0/nodes
GET /v1/nodes/nod_a1c3e902
{
  "data": [
    {
      "id": "nod_a1c3e902",
      "cluster_id": "clu_4e91b2a0",
      "hostname": "train-a-03",
      "state": "running",
      "gpu_model": "H100-SXM",
      "gpu_count": 8,
      "memory_gb": 2048,
      "image": "ubuntu-22.04-cuda12",
      "private_ip": "10.64.2.13",
      "activated_at": "YYYY-MM-DDTHH:MM:SSZ"
    }
  ]
}

state is one of pending, provisioning, running, stopped, reimaging, rescue, error, or terminated.

Lifecycle actions

Actions are posted against a node. Send an Idempotency-Key. The response is an action record; poll the node or wait for a webhook for completion.

POST /v1/nodes/nod_a1c3e902/actions
Content-Type: application/json
Idempotency-Key: 7f2a1c90-3e4b-4d8a-9c11-2b6e0f8a4d21

{
  "action": "reimage",
  "image": "ubuntu-22.04-cuda12"
}
{
  "data": {
    "id": "act_6c81d4e2",
    "node_id": "nod_a1c3e902",
    "action": "reimage",
    "state": "queued",
    "created_at": "YYYY-MM-DDTHH:MM:SSZ"
  }
}

Supported action values:

  • reboot — soft reboot; node returns to running
  • power_off — graceful stop → stopped
  • power_on — start a stopped node → running
  • reimage — requires image; node enters reimaging
  • rescue — boot into rescue environment → rescue

Invalid transitions (for example power_on while already running) return HTTP 409 with {"error":"conflict","message":"..."}.

Images

GET /v1/images
{
  "data": [
    {
      "slug": "ubuntu-22.04-cuda12",
      "name": "Ubuntu 22.04 LTS with CUDA 12",
      "os": "linux",
      "arch": "x86_64",
      "gpu_models": ["H100-SXM", "A100-SXM"]
    }
  ]
}

SSH keys

GET /v1/ssh-keys
POST /v1/ssh-keys
DELETE /v1/ssh-keys/{id}
POST /v1/ssh-keys
Content-Type: application/json
Idempotency-Key: b9e2c104-6a77-4f01-8d3e-1c5a9f0e2b44

{
  "name": "deploy-bot",
  "public_key": "ssh-ed25519 AAAA... [email protected]"
}
{
  "data": {
    "id": "key_2f8d91c0",
    "name": "deploy-bot",
    "fingerprint": "SHA256:...",
    "created_at": "YYYY-MM-DDTHH:MM:SSZ"
  }
}

Keys attached to the account are injected on reimage and first boot. Removing a key does not revoke it from nodes already provisioned; rotate host access separately if needed.

Webhook events

  • node.state_changed — any transition of state
  • node.reimage_completed — reimage finished successfully or failed

Signature verification and delivery semantics are described in the overview.

Adding capacity

New nodes and clusters are not created with a free-form POST /v1/nodes. Place an order with service: "ai_infrastructure" as documented under orders. Once the service order is signed and provisioned, the cluster and nodes appear in the inventory endpoints above.

Automating a cluster?

We can issue scoped credentials and a sandbox cluster so you can wire lifecycle actions before touching production nodes.