TrixOS API

Everything the TrixOS panel does goes through this API: the web interface uses exactly these endpoints. This reference is generated from the code of release 0.9.0 and lists all 177 endpoints of the native API, plus the TenantOS-compatible and internal ones.

Base URL

Each installation serves its own API. All native endpoints live under /api/v1 of your panel:

https://panel.example.com/api/v1

Your panel also serves this specification itself, for the version it runs: Swagger UI at /api/docs and the JSON at /api/docs/json, for signed-in admins (an admin API token works too; TRIXOS_API_DOCS=publicopens them to everyone, off turns them off). The file for this reference is openapi.json.

Authentication

API tokens

Scripts and other systems use API tokens. Create one under Users → API tokens in the panel or with POST /users/{id}/tokens, and send it in every request:

Authorization: Bearer 12|kD8s0Vt2…

A token is <id>|<secret>, the same format TenantOS used. The secret is shown once; only its hash is stored. A token can expire, can be limited to source IP addresses, and never has more rights than its user. Its scopes narrow it further:

  • *
  • servers:read
  • servers:power
  • servers:console
  • servers:provision
  • servers:write
  • ipam:read
  • ipam:write
  • users:read
  • users:write
  • admin

* means everything the token’s user may do. Scopes are enforced on every request: a token without the scope for an endpoint gets 403, and endpoints outside these scopes need admin.

Browser sessions

The web interface signs in with POST /auth/login, which sets an httpOnly, SameSite=Strict session cookie. With two-factor authentication on, POST /auth/mfa completes the sign-in. Requests that change something must send the header X-Requested-With: trixos; it protects cookie sessions against cross-site requests.

Requests and responses

Requests and responses are JSON, and every request is validated against the schema shown in this reference. Most lists return an array; paged lists such as GET /servers return {"data": [...], "total": n, "page": 1, "perPage": 50} and take page and perPage.

Errors

Errors have one shape and a stable code:

{
  "error": {
    "code": "LOCKED",
    "message": "Another destructive job is already running for this server.",
    "details": null
  }
}
CodeHTTPMeaning
BAD_REQUEST400The request is invalid; details lists the fields.
UNAUTHORIZED401No valid session or token.
FORBIDDEN403Signed in, but not allowed: wrong role, missing scope or not your server.
NOT_FOUND404The object doesn’t exist or isn’t visible to you.
CONFLICT409The change conflicts with the current state, for example an overlapping rack placement.
PROTECTED423Legacy protected flag on a server.
SUSPENDED423The server is suspended for your level.
MAINTENANCE423
LOCKED409Another hardware job is running for this server.
DRIVER_ERROR502The BMC, switch or another device answered with an error.
RATE_LIMITED429Too many requests; wait and retry.
LICENSE_REQUIRED402The panel is locked or read-only because of its license; GET /license says why.
INTERNAL500Unexpected error on the panel; see its logs.

Rate limits

1,200 requests per minute per token, or per IP address without a token. Sign-in is limited to 10 attempts per minute. Over the limit, the API answers 429.

Hardware actions and jobs

Anything that touches a server’s hardware runs as a job:

  1. Destructive actions (power off, reset, cycle, reinstall, rescue, disk wipe, password reset, port shutdown) need the server’s hostname in the body as "confirm": "web-01". Endpoints that need it are marked in this reference.
  2. The API answers 202 with the job. Follow it with GET /jobs/{id} or the job websocket.
  3. A job ends as success, failed or cancelled. Only one hardware job per server runs at a time; a second one gets 409 LOCKED.
  4. While the panel is in dry-run mode, jobs run through all steps without touching hardware and carry dryRun: true.

Websockets

PathSends
/api/v1/ws/jobs/{id}The job and its new log lines as they happen: {"kind": "job", "job": …}, {"kind": "log", "log": …}
/api/v1/ws/eventsEvery job state change: {"jobId", "serverId", "status"}
/api/v1/ws/console/{token}A console session for a one-time token from POST /servers/{id}/console: text frames for serial, binary RFB (subprotocol binary) for KVM

Versions

The API is versioned with TrixOS itself: the spec’s version is the release. Changes to endpoints are listed in the changelog.

Sections

SectionEndpointsCovers
Authentication7Browser sessions and two-factor authentication. Scripts use API tokens instead.
Servers26Servers, their BMC connection, inventory, disk health and notes.
Power5Power state and power actions, and raw BMC commands.
Console4One-time console tokens for serial, graphical KVM and the BMC web interface.
Provisioning8Everything that boots a server over PXE: reinstall, rescue, hardware collection, disk wipe, password reset. All of these start a job and answer 202.
Jobs4Jobs and their logs. Every hardware action runs as a job.
Monitoring5Live sensors and stored graphs for bandwidth and sensors.
IP addresses14Subnets, address assignments and reverse DNS.
Network & sites30Sites (datacenters), switches, switch ports and site agents.
Datacenters & racks6Datacenter overview and rack management. Rack placement of a server is part of the server (PATCH /servers/{id}).
Firmware10The firmware catalogue and the installed BIOS and BMC versions.
OS catalogue17OS profiles, rescue systems and tools, disk layouts, post-install scripts and custom ISOs.
Users11Users, SSH keys, login history and per-server permissions.
API tokens3Create and revoke API tokens. The secret is returned once.
Audit log2Every change made through the UI or the API.
System13Dashboard figures, settings, webhooks and system status.
Inventory & stock7Hardware parts across all servers and in stock (spare, defective, RMA, retired).
License5License state, activation and check-ins. While the panel is locked or read-only, other endpoints answer 402 LICENSE_REQUIRED.
TenantOS-compatible API35The endpoints of the TenantOS API that integrations use, answered the TenantOS way.
Installer & site agent16PXE boot files, installer callbacks and the site agents.