> Toden documentation. For the full index fetch /llms.txt. Every page is available as Markdown by appending .md to its URL. Identity verification uses /api/kyc, Risk Intelligence uses /api/v1; they are separate contracts with different error shapes. Never invent an endpoint, field or enum value: read the API reference page for the operation first. # Roles and permissions > Built-in roles, custom roles, the full permission list, how invitations work and the rules that protect organisation ownership. Every person in your organisation holds exactly one role, and a role is a named set of permissions. Toden ships four built-in roles and lets you create your own. This page is for organisation owners and admins who manage a team, and for compliance leads who need to show who can do what. ## Where to find it | Task | Console location | Permission needed | | ---------------------------------------------- | ---------------------------------- | ------------------------------------------------------------------------------ | | See members and pending invites | **Organisation → Team** | `team:read` | | Invite someone, change a role, remove a member | **Organisation → Team** | `team:invite`, `team:change_role`, `team:remove_member` | | Create or edit roles | **Settings → Roles & Permissions** | `roles:read` to view, `roles:create`, `roles:update`, `roles:delete` to change | Roles belong to one organisation. If you are a member of several organisations, you can hold a different role in each. ## Built-in roles Each organisation is created with four system roles. System roles cannot be deleted or renamed. | Role | What it holds | Can it be edited? | | ---------- | ---------------------------------------------------------- | ------------------------------------------ | | **Owner** | Every permission, including any added in future | No. It is fully locked | | **Admin** | Every organisation permission except `organization:delete` | Permissions and description can be changed | | **Member** | Every permission that ends in `:read` | Permissions and description can be changed | | **Viewer** | Every permission that ends in `:read` | Permissions and description can be changed | Member and Viewer start with the same read-only set. They are separate roles so that you can widen one (for example, let Members run spot checks) without touching the other. > **Note** > > Read-only roles see API keys in masked form. The full value of a publishable key is shown only to roles that hold `api_keys:create`. See [API keys](/get-started/console/api-keys). ## Custom roles ### Open Roles & Permissions Go to **Settings → Roles & Permissions** and choose **New role**. ### Name the role Give it a name (2 to 50 characters, unique in your organisation) and an optional description of up to 200 characters. ### Pick permissions Tick the permissions the role grants, then choose **Create role**. The list only offers permissions that your own role holds. ### Assign it Assign the role when you invite someone, or change an existing member's role from **Organisation → Team**. Rules that apply to every role change: * **You cannot grant what you do not hold.** Adding a permission that your own role lacks is refused with `invalid_permissions`. You can still remove permissions from a role, so a less privileged admin can always reduce access. * **You cannot place someone in a stronger role than yours.** Inviting a person into, or moving a member to, a role with permissions you do not hold is refused with `403 role_escalation_forbidden`. * **A role in use cannot be deleted.** Reassign its members and revoke its pending invites first, otherwise the request returns `409 role_in_use`. ## Permission reference Permission keys follow the pattern `resource:action`. The set is fixed by Toden: you choose which keys a role holds, but you cannot invent new ones. | Group | Permission keys | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | API keys | `api_keys:read`, `api_keys:create`, `api_keys:revoke` | | API logs | `api_logs:read` | | Webhooks | `webhooks:read`, `webhooks:create`, `webhooks:update`, `webhooks:delete`, `webhooks:test`, `webhooks:retry` | | Workflows | `workflows:read`, `workflows:manage` | | Verifications | `verifications:read`, `verifications:review`, `verifications:export`, `verifications:delete`, `key_people:manage`, `sessions:create`, `sessions:expire` | | Spot checks | `spot_checks:read`, `spot_checks:create`, `spot_checks:delete`, `business_checks:read`, `business_checks:create`, `business_checks:delete` | | Analytics | `analytics:read` | | Billing | `billing:read`, `billing:request_topup`, `billing:cancel_topup`, `billing:set_threshold`, `payment_methods:read`, `payment_methods:manage`, `billing_documents:read`, `auto_topup:read`, `auto_topup:manage` | | Team | `team:read`, `team:invite`, `team:revoke_invite`, `team:remove_member`, `team:change_role` | | Roles | `roles:read`, `roles:create`, `roles:update`, `roles:delete` | | Onboarding | `onboarding:read`, `onboarding:update`, `onboarding:submit`, `onboarding:appeal` | | ID types | `id_types:read` | | Customers and compliance | `identity:read`, `business_identity:read`, `identity:manage`, `identity:delete`, `screening:read`, `screening:manage`, `signals:read`, `alerts:read`, `alerts:manage` | | Risk Intelligence | `risk_assessments:read` | | Continuous monitoring | `monitoring_subscriptions:read`, `monitoring_subscriptions:manage`, `monitoring_policies:read`, `monitoring_policies:manage`, `monitoring_runs:trigger` | | Cases and investigations | `cases:read`, `cases:manage`, `cases:create`, `cases:assign`, `cases:resolve`, `cases:reopen`, `cases:evidence`, `cases:notes`, `cases:sensitive`, `sars:file`, `sars:export` | | Monitoring rules | `monitoring:read`, `monitoring:manage` | | Fraud Monitoring | `fraud_prevention:read`, `fraud_prevention:manage`, `fraud_prevention:override`, `crypto_addresses:reveal` | | AI features | `intelligence:use`, `intelligence:manage`, `intelligence:privacy` | | Audit logs | `audit_logs:read` | | Organisation | `organization:update`, `organization:delete` | | Security | `security:manage` | A few keys are deliberately separate from the broader key beside them, so that a sensitive act is never granted by accident: | Key | Why it stands alone | | --------------------------------------------- | ---------------------------------------------------------------------------------------------- | | `identity:delete` | Removing a customer record is not part of `identity:manage`, which covers creating and editing | | `sessions:expire` | Ending a live verification link revokes a credential, so it is separate from `sessions:create` | | `sars:file` | Marking a SAR or STR as filed. The person who drafted a report can never file it | | `sars:export` | Downloading the full report is a disclosure, so it is not covered by `cases:read` | | `payment_methods:manage`, `auto_topup:manage` | Changing saved cards or unattended card charging | ## Inviting members Open **Organisation → Team**, choose **Invite team member**, enter the email address and select a role. * The invitation is emailed as a link and expires after **7 days**. Inviting the same address again replaces the earlier invitation. * The Owner role cannot be assigned through an invitation. * The link works only for the address it was sent to. If that person has no Toden account yet, they create one while accepting, and their email address counts as verified. * Pending invitations are listed on the Team page with who sent them and when they expire. You can resend or revoke one from there. ## Ownership protection * An organisation always keeps at least one Owner. Demoting or removing the last Owner is refused. * You cannot change your own role or remove yourself. * The Owner role cannot be assigned from the Team page, and it cannot be modified or deleted. ## How permissions are enforced Permissions are checked on Toden's servers for every console action. The console hides controls you cannot use, but that is a convenience: a request made without the required permission is refused with `403` and a body that lists the missing keys. ```json { "error": "Insufficient permissions", "required": ["api_keys:create"] } ``` Roles govern people signed in to the console. API keys are not tied to a person or a role: what a key may call depends on its type (publishable or secret) and its environment. See [Authentication](/get-started/authentication). Role changes and team changes are written to the [audit log](/get-started/console/audit-logs) as `role.created`, `role.updated`, `role.deleted`, `team.invite_sent`, `team.invite_accepted`, `team.member_role_changed` and `team.member_removed`. ## Related * [API keys](/get-started/console/api-keys) * [Audit logs](/get-started/console/audit-logs) * [Authentication](/get-started/authentication) * [Go live](/get-started/go-live)