Permissions decide what an API key or a teammate can do. Every permission is a colon-separated string like api:address:read, read left to right - and how many segments it has depends on which service it belongs to. This page is the access model itself; for who sits in which seat on your team, see Members & roles.
api · rpc · mgt · vks read · write · delete Exact-match checks Fixed at creation
A permission is a colon-separated string, read left to right: the scope (the service - api, rpc or mgt), the resource (the object it covers, like address or member), and the action (read, write or delete).
The Platform API uses all three. RPC exposes a single capability, so it drops the resource; the Management API inserts a level segment - workspace or project - before the resource, giving it four parts:
| Service | Format | Example |
|---|---|---|
| Platform API | api:{resource}:{action} | api:address:read |
| Blockchain RPC | rpc:{action} | rpc:call |
| Management API | mgt:{level}:{resource}:{action} | mgt:workspace:member:write |
Checks are exact string match - a permission grants only the action it names, with no implied hierarchy. A key with api:address:read can list and read addresses, but registering one needs api:address:write. Grant every action you actually use.
Three verbs cover almost every resource, and they mean the same thing in every scope:
Lists and views objects. Read-only - never changes state.
Creates new objects and updates existing ones.
Permanently removes objects. Not every resource supports it.
Two operations use a fourth action, call, instead: rpc:call sends a node request, and api:simulate:call runs a transaction simulation.
Permissions never float free - something carries them. A key and a member each get their set a different way:
Carry a fixed set chosen at creation. An API key gets the api permissions you pick (scoped to one project); an RPC key gets rpc:call; a management key gets a safe subset of mgt permissions.
A member's role supplies default permissions. Authorized users can separately manage the member's vks:access grant through a dashboard session.
There is no endpoint to widen or narrow a key after it exists. To change what a key can do, revoke it and create a new one with the permissions you want.
Pick a scope to see every permission it defines. The scope - the first segment of the string - is also the service the permission belongs to.
Platform API - blockchain operations on a project.
Form api:{resource}:{action}. Each resource supports a different mix of actions:
| resource | read | write | delete |
|---|---|---|---|
address | yes | yes | yes |
limits | yes | - | - |
activity | yes | - | - |
transaction | yes | - | - |
blockchain | yes | - | - |
balance | yes | - | - |
asset | yes | yes | - |
subscription | yes | yes | yes |
channel | yes | yes | yes |
public_key | yes | yes | yes |
invoice | yes | yes | yes |
token_tag | yes | yes | yes |
address_tag | yes | yes | yes |
One more sits outside the grid: api:simulate:call runs a transaction simulation.
api:activity:read authorizes GET /v2/activity. Transaction list and detail operations require api:transaction:read. Grant both permissions if your integration reads activity and transactions.
Management API - workspace and project administration.
Form mgt:{level}:{resource}:{action}. Permissions split into a workspace level and a project level - read each cell as the full four-segment string.
Workspace level - mgt:workspace:{resource}:{action}
| resource | read | write | delete |
|---|---|---|---|
self | yes | - | - |
member | yes | yes | yes |
project | yes | yes | - |
rpc_key | yes | yes | - |
mgt:workspace:member:* also covers assigning, updating and removing a project's members - there is no separate mgt:project:member:* string.
Project level - mgt:project:{resource}:{action}
| resource | read | write | delete |
|---|---|---|---|
self | - | - | yes |
api_key | yes | yes | - |
mgt:project:self:delete deletes the project itself; nothing else uses the project-level self resource.
Blockchain RPC - direct node access across every chain.
Form rpc:{action} - no resource segment.
| Permission | Grants |
|---|---|
rpc:call | Send JSON-RPC and gRPC requests to any supported chain |
A management key can list and read API/RPC key metadata with the corresponding read permission. Creating and revoking API keys requires mgt:project:api_key:write; creating and revoking RPC keys requires mgt:workspace:rpc_key:write.
The following actions require a user session in the dashboard and the appropriate workspace role:
- Management keys - listing, viewing, creating and revoking. Neither
mgt:workspace:mgt_key:readnormgt:workspace:mgt_key:writecan be granted to a management key. - VKS keys - listing, viewing, creating and revoking; available to workspace owners and admins.
- Workspace deletion or transfer - available only to the workspace owner.
Previously granted access to Management keys may still appear in saved key details. Those permissions no longer authorize these operations and cannot be selected when issuing a new key.
Roles supply the default permission sets below. A workspace role grants mgt permissions; a project role grants api permissions. Workspace Owners and Admins have VKS access automatically. A Member needs an explicit vks:access grant through the dashboard; this does not change their project role or any API key's permissions.
| Role | Level | Permission set |
|---|---|---|
| Owner | Workspace | Everything an Admin has, plus deleting or transferring the workspace. One owner per workspace, set at creation. |
| Admin | Workspace | Full mgt and api - manage members, projects, and keys, but not delete or transfer the workspace. |
| Member | Workspace | Read-only at the workspace level; reaches only the projects they are assigned. |
| Editor | Project | api read, write, and delete on that project's resources. |
| Viewer | Project | Read project resources and simulate transactions (api:simulate:call). |
A workspace Owner or Admin manages every project automatically; a Member needs an Editor or Viewer seat on each project to reach it. See Members & roles for the seat descriptions and how to invite or change someone.
A valid key without the required permission receives 403 Forbidden. Check the operation’s required grant and the key’s permissions. To change a key’s grants, issue a replacement and revoke the old key.
Every published VKS operation requires vks:access on a workspace VKS key, including reads, creation, deletion and send. This is access to the public VKS API as a whole, without separate read/write grants. Issue the key in the Dashboard; Dashboard role grants do not establish a public Management key-issuance operation. See VKS.