Permissions
Product access, presets and the permissions that API keys can use.
Product permissions determine what a user or an API key can read and change. Organization roles select the initial access preset. An Owner can customize access for any member. An Admin can customize access for Members and Admins, but cannot change an Owner's access.
An organization role alone does not authorize a product operation. A restricted Owner can have less product access than a Member.
Permission levels
Each resource has one of these levels:
| Level | Allows |
|---|---|
| No access | No reads or changes to that resource. |
| Read | Supported reads of that resource. |
| Read and write | Reads and supported changes, including deletion. |
Some resources, such as observed signals, support reads only. Write permission does not separate editing from deletion. Permissions preserve organization boundaries and existing ownership rules.
Access presets
| Preset | Product access | Initial role default |
|---|---|---|
| View only | Read product data. | None. Select it to restrict access. |
| Standard use | Product reads, ordinary record changes, discovery, imports and one-off execution. | Member. |
| Full product access | Every supported product permission. | Admin and Owner. |
Standard use includes changes to accounts, people, campaigns, campaign membership, custom fields and input files. It does not include managing monitoring, schedules, integrations, webhooks or shared links.
Capability groups let an Owner or Admin adjust common permissions together. For example, Manage monitoring adds writes to monitors and schedules. Advanced permissions lets the editor choose a level for each resource.
A preset saves an explicit set of permissions. Later changes to a preset do not silently expand existing access. Changing an organization role also preserves the member's current product access. Applying role defaults requires an explicit access save.
API keys and their owners
Each API key belongs to one user in one organization. A new key starts with a copy of its owner's current product access. The owner can restrict the key further.
For each resource, effective key access is the lower of:
- The level assigned to the key.
- The owner's current level in the key's organization.
For example, a key assigned monitor write access cannot change a monitor when its owner currently has monitor read access. Reducing the owner's access takes effect on the next request. Restoring owner access can make the key's previously assigned levels effective again. Increasing owner access does not add levels that the key was never assigned.
Removing the owner's organization membership disables the key's product access. Product permissions grant no organization administration or billing rights to an API key.
Configure access in the web app:
- Open Settings, then Organization to invite a member or edit product access.
- Choose a preset. Adjust capabilities or Advanced permissions when needed.
- Review the change preview and any impact on API keys before saving member access.
- Open Settings, then API Keys to create a key with current access or restrict it.
- Open an existing key to compare assigned, effective and owner-blocked permissions.
An invitation applies its selected role and product access when the recipient accepts it. A stale access save preserves the stored assignment and asks the editor to refresh.
Operation requirements
Every operation checks the resources that it reads or changes. Examples:
| Operation | Required access |
|---|---|
get_campaign | campaign.read. Embedded data also needs its resource reads. |
update_account | account.write. |
add_accounts_to_campaign | campaign.read, account.read and campaign_account.write. |
run_monitor | monitor.read and run.write, plus access to the inputs and effects of that run. |
rotate_webhook_secret | webhook.write. |
get_me | credit_balance.read. The returned role is information, not a product permission. |
A request that affects several resources needs every required level. Scheduling needs schedule write access, even when the caller can run the same work once. Starting discovery or import also needs the reads and record writes that the run performs. A webhook change needs webhook write access.
See Campaigns, Discovery, Monitors and the API reference for operation behavior.
Restricted response data
A readable object can contain sections that require additional permissions. The response omits or sets those sections to null and identifies them in restricted. For example, campaign fields can be null when the caller cannot read custom fields. Campaign counts and linked records follow their own read boundaries.
An explicitly requested resource without its required read permission gives 403. A linked ID does not grant access to the linked object's contents. Downloads and shared reads keep the represented data's read requirements.
Permission denials
A missing level gives 403 access_denied. The error identifies the resource, action and operation. The request starts no work, changes no product data and spends no credits.
Read error.details and ask an Owner or Admin to review the user's access and the key's assigned limit. Retrying the same request does not repair a missing permission. See Errors.
Queued and scheduled work rechecks current authority before starting. Missing authority blocks a new start without spending credits. An authorized running operation can finish unless it is canceled. An authorized member can reauthorize blocked recurring work in the web app.
Organization administration remains role-controlled. Owners and Admins manage members and invitations; billing and financial history require an Owner session. Product permissions do not replace those role checks.