A workspace is where your team works together. You invite teammates to a workspace and give each one a role that controls what they can see and do. Inside a workspace, projects group your monitoring work, and you can grant per-project access on top of the workspace role.
This page explains the roles and how to invite people. For the exact permission each role carries, see Permissions.
Workspace · Owner, Admin, Member Project · Editor, Viewer Invite by email Role maps to permissions
Every member of a workspace has exactly one workspace role; it sets their baseline access across the whole workspace.
The person who creates the workspace. Everything an admin can do, plus deleting or transferring the workspace. There is exactly one owner, and it is never handed out through an invitation.
Manages members, projects, invitations, and API keys, with implicit access to every project. Can do everything except delete or transfer the workspace.
Read-only at the workspace level. Sees only the projects they are explicitly assigned to.
For VKS, an authorized user can separately manage a member’s vks:access grant in the dashboard. Role permissions and explicit VKS access are described in Permissions.
On top of the workspace role, a member can be assigned a role on individual projects.
Read and write access to the project's resources: addresses, channels, invoices, and so on.
Read project resources and simulate transactions without broadcasting them.
The workspace role sets the baseline; project assignments add reach into individual projects on top of it.
| Workspace capability | Owner | Admin | Member |
|---|---|---|---|
| See the workspace | yes | yes | yes |
| Manage members and invitations | yes | yes | no |
| Create and manage projects | yes | yes | no |
| Create and manage keys (API, RPC, management) | yes | yes | no |
| Reach every project automatically | yes | yes | no |
| Delete or transfer the workspace | yes | no | no |
| Project capability | Editor | Viewer |
|---|---|---|
| Read project resources | yes | yes |
| Create, update, and delete project resources | yes | no |
A workspace member does not inherit project access; they must be assigned Editor or Viewer on each project they should reach, and they see only the projects they are assigned. Removing a member from the workspace revokes all of their project assignments at once.
Workspace admins add teammates from the dashboard under workspace settings.
Send the invite. From workspace settings, enter the teammate's email, pick the workspace role (admin or member), and optionally assign project roles.
They accept. Once the invitee accepts, they become a workspace member with the role you chose.
Adjust anytime. Change their workspace role or project assignments from the same settings, or revoke access by removing them.
You can also manage members programmatically with the Management API using a management key that carries the mgt:workspace:member:write permission.
Invitations have the statuses below. Any workspace admin can revoke a pending invitation; unanswered invitations expire at the specified deadline.
| Status | Meaning |
|---|---|
| pending | Invitation sent, waiting for a response |
| accepted | The invitee accepted and a membership was created |
| declined | The invitee declined the invitation |
| revoked | An admin cancelled the invitation |
| expired | No response before the expiration time |
Every workspace has exactly one owner, set when it is created. Invitations and role changes only assign admin or member; ownership is never granted this way. Only the owner can delete or transfer the workspace.