Skip to main content
Access in Anyreach is controlled by scopes, not by a single role flag. Each member of an organization is assigned an organization role, that role grants a set of scopes, and every protected action checks for one of the scopes it needs. The dashboard reads the caller’s scopes and hides any control they cannot use, so a member only ever sees what their role permits. There are two interactive roles you assign to people: admin and viewer. admin carries the full scope set; viewer carries read-only scopes. You pick one of these when you invite a member or change their role.
Roles are the package; scopes are the actual permissions. Two members with the same role always have the same scopes. This page documents the scope catalog so you can reason about exactly what each role can do.

​
Roles

Only admin and viewer appear in the role picker when you invite or update a member. See Members and invitations for how to assign them.

​
How scope gating works

Scopes are checked in two layers:
  • Backend. Each endpoint declares the scope(s) it accepts. A request succeeds only if the caller’s token carries at least one of them; otherwise it is rejected with 403.
  • Frontend. The dashboard fetches your scopes and renders a control only when you hold a matching scope. Missing the scope hides the button or page rather than showing a disabled state. Pages that require a scope you lack show a no-access fallback.
You can read your own scopes for the current organization from the admin API:
This returns the flat list of scope strings granted to you in that organization. Any authenticated member can call it for themselves; reading another member’s scopes requires members:read or members:manage.

​
Organization-administration scopes

These scopes gate the account, members, and billing surfaces. They live in the admin service.
members:manage and billing:manage are admin-only. A viewer can list members with members:read but cannot invite, remove, or re-role anyone, and cannot open billing.

​
Resource scopes

Every product area exposes its own permissions through the API service. Most areas follow a read versus manage split: read lets you view, manage lets you create, edit, and delete. Conversations add finer-grained scopes for sensitive data and for placing calls.

​
Conversations

The split between conversations:read and conversations:read_sensitive controls who can see protected fields. See Permissions and data access for what each level exposes.

​
Telephony and agents

​
Email

​
Assessments, workflows, knowledge base, and campaigns

assessments:read and assessments:manage cover the evaluation suite — metrics, scorecards, scorecard runs, and assessment results — under a single read/manage pair at the API.

​
How scopes reach a request

The role and its scopes are resolved differently depending on how you authenticate:
  • Dashboard users sign in and receive a token bound to the organization they have open. Their scopes come from the admin or viewer role assigned to them in that organization.
  • User personal access tokens (pat_) act as the user, so they carry the user’s scopes for the organization named in the required X-Anyreach-Org header.
  • Organization API keys (ak_) carry their organization implicitly and are granted scopes when the key is created.
See Authentication for the full token model.

Members and invitations

Invite people and assign the admin or viewer role.

Conversations data access

What the sensitive-read scope exposes.