Understand team roles, the permissions each role grants by default, the full list of available permissions, and how custom roles work.
Your team in the dashboard can have as many members as you need, and every member is assigned a role that determines what they can see and do. This page explains each role, the permissions it grants by default, the full list of available permissions, and how to build your own custom roles.
A team has one Owner and any number of members. Each member is assigned a single role.
The Owner always has every permission. Ownership is set when the team is created or via an ownership transfer — it cannot be assigned by invite.
Permissions are granular and named category.action (for example, smart-links.manage). A role is simply a named bundle of default permissions.
Extra permissions can be granted on top of a role's defaults. These are additive — for example, you can give a Viewer one extra capability without switching them to a Custom role.
A Custom role has no default permissions. You build it up entirely by ticking individual permissions from the grouped list.
A member's effective permissions = their role's defaults + any extra permissions granted to them.
The roles you can assign when inviting or editing a member are Admin,
Member, Developer, Viewer, and Custom. The Owner role is
not in this list — it is set only at team creation or via ownership transfer.
Full control over the team, billing, and all settings. Always has every permission. Set at team creation or via ownership transfer; cannot be assigned by invite.
Admin
Full access to everything except deleting the team.
Member
Create and manage accounts, links, pixels, reports, and creator tools. No team-management or billing access.
Developer
Create and use API keys, webhooks, and integrations. Mostly view-only on creator features.
Viewer
View-only access to all data and reports.
Custom
A custom set of permissions you choose yourself.
When deciding which role to assign:
Admin — for trusted co-managers who should be able to do everything you can, except delete the team. Admin equals every permission except Delete the team.
Member — for day-to-day operators. They get full operational access to accounts, links, pixels, free trials, reports, and developer/AI/creator tools, but no team management, no billing, and they cannot purchase credits.
Developer — for engineers integrating with the API. They get full control of API keys, webhooks, integrations, and data exports, but are view-only on creator features (accounts, smart links, free trials, and so on).
Viewer — for stakeholders who only need to look. Their defaults are exactly "all view permissions" — every *.view capability and nothing that creates, edits, deletes, or manages.
Custom — when none of the presets fit. A Custom role starts empty; you tick individual permissions from the grouped list below.
Need a role that's almost right? Instead of building a Custom role from
scratch, assign the closest preset and grant a few extra permissions on
top. See Custom roles & extra permissions.
The tables below list every available permission, grouped by category. Each row shows what the permission allows, its internal key (useful for API and role automation), and whether each role gets it by default (✓) or not (—).
The Owner is granted every permission, so it is ✓ on every row. Custom roles start with no default permissions and are therefore omitted from the matrix.
A Custom role starts with no permissions. You build it up entirely by ticking individual permissions from the grouped list above. Use this when a member needs a unique combination of capabilities that none of the presets provide.
Any role can be granted individual extra permissions beyond its defaults. These are additive, so you don't have to switch a member to a Custom role just to give them one more capability — for example, you can grant a Viewer a single *.manage permission while keeping all their view-only defaults.
A member's effective access is always: role defaults + any extra permissions granted to them
Email notification defaults
By default, Owner, Admin, and Member roles receive
authentication-action-required emails (for example, when an account needs
re-authentication).