GET/api/v1/list-all-permissions

List all permissions

Lists every permission type the platform defines, each with the numeric id that the role editing endpoints expect and the key name the API uses for it.

AccessRequires a signed-in caller

This is the catalogue of permissions the platform recognises. It is the same for every organisation and workspace, and it does not report what the caller holds: for that, read the memberships in GET /api/v1/get-user-info, where each workspace carries the caller's role and its permissions.

Use it to resolve a permission to its UID before editing a role. That UID is the rule_uid that POST /api/v1/add-perm-to-role and POST /api/v1/remove-perm-from-role take, so read this list rather than hard-coding ids. RuleName is the key the API identifies the permission by, such as MANAGE_WORKSPACE. For what each one allows in practice, see the Permission reference and Roles and permissions.

The Owner role bypasses all permission checks, so a member holding it is not limited by the permissions in this list. The sample response below is shortened: a live call returns every permission the platform defines, in one flat list.

bash

curl "$SQRL_API/api/v1/list-all-permissions" \
  -H "authorization: Bearer $SQRL_TOKEN"

const res = await fetch(`${process.env.SQRL_API}/api/v1/list-all-permissions`, {
  headers: { authorization: `Bearer ${process.env.SQRL_TOKEN}` },
});
const { Rules } = await res.json();

rust

let res = client
    .get(format!("{}/api/v1/list-all-permissions", api_base))
    .bearer_auth(&token)
    .send()
    .await?;

Response200 OK

{
"Rules": [
  { "UID": 3, "RuleName": "MANAGE_ROLE" },
  { "UID": 4, "RuleName": "MANAGE_PERMS" },
  { "UID": 6, "RuleName": "PAYMENT_APPROVE" },
  { "UID": 8, "RuleName": "VIEW_BALANCES" }
]
}

Was this page helpful?