Skip to content

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.

AuthenticateBrowse the reference

The basics ​

Base URLhttps://<your-shellius-host>/api — it is your own deployment. There is no central API.
FormatJSON in, JSON out, Content-Type: application/json.
AuthenticationAuthorization: Bearer <access token>. See Authentication.
TenancyEvery call is scoped to the organisation of the signed-in user. There is no organisation parameter.
AuthorisationPermission keys, not role names. Each endpoint in the reference lists the key it requires.

Every response uses one envelope:

json
{ "success": true, "data": { }, "meta": { } }
json
{ "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.

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.

Was this page helpful?No, tell us why