Shellius API
The portal and the shellius terminal client are both clients of one REST API. Anything you can do in the portal, you can do with a request — subject to the same permissions, the same production approval rules, and the same audit log.
The basics
| Base URL | https://<your-shellius-host>/api — it is your own deployment. There is no central API. |
| Format | JSON in, JSON out, Content-Type: application/json. |
| Authentication | Authorization: Bearer <access token>. See Authentication. |
| Tenancy | Every call is scoped to the organisation of the signed-in user. There is no organisation parameter. |
| Authorisation | Permission keys, not role names. Each endpoint in the reference lists the key it requires. |
Every response uses one envelope:
{ "success": true, "data": { }, "meta": { } }{ "success": false, "error": { "code": "PERMISSION_DENIED", "message": "…" } }There are no long-lived API tokens yet
Shellius does not currently issue personal access tokens or service-account keys. A script authenticates the way a person does: it signs in, receives a short-lived access token and a refresh token, and refreshes as needed. Create a dedicated user with a narrow role for automation, and read Authentication before building on this.
Guides
Reference
266 endpoints across 33 resources.
Identity
Team
Inventory
Access
Activity
Settings
Host agent
System
How this reference is built
The reference pages are generated from the backend's route files: the method and path, the permission guard, the rate limiter and the request validation schema are read from the code. Response bodies are not generated, because they cannot be read reliably from the source — each endpoint shows the envelope only. When a field matters to you, call the endpoint against a test deployment.
The API is versioned with the product. It has no separate version prefix, and no compatibility promise across minor releases yet; check the changelog when you upgrade.