Read, Write, and sensitive actions
Each resource has its own permissions. Read and Write are independent: Write does not automatically include Read. Give a teammate both if they need to open a page and edit its data. A backend that only performs one write operation may need only that operation’s Write scope.
These examples are starting points, not role presets. Use the scope catalog
and each API operation’s required scope for the full list. Permission to use one page does not
grant every related resource: a campaign reader does not automatically get analytics or payouts.
Configure a teammate
- Select the company and open Settings → Team.
- Invite a teammate, or open Manage access for an existing member.
- Choose their role and select Read, Write, and any named sensitive actions for each resource. An Owner retains full company access. Admin and Employee access can be customized.
- Save. A manager cannot grant permissions they do not have. If an existing member has broader access than the manager, those selections remain visible and read-only; an owner must manage them.
What the teammate sees
Navigation, settings tabs, and edit controls follow access for the selected company. Read-only members can browse permitted data. Restricted analytics show an access notice instead of misleading zero metrics. Members can edit their personal profile and inspect their own company access under Settings → Profile, even without permission to list the team. Access refreshes when the window regains focus or the company context refreshes. Server checks run independently: leaving an old tab open does not authorize an operation after access is removed. Billing prices and wallet details require their own Read permissions; ordinary page loading does not require permission to inspect billing details.Messages Read covers SideShift’s read APIs. New write-capable embedded chat sessions require
Messages Write. An already-issued third-party chat session has its own lifetime; do not rely
on a SideShift scope change alone to immediately revoke that provider session.
How integration access is limited
Resource ownership, subscription eligibility, sandbox restrictions, and sensitive-action rules
also apply. A scope is permission to request an operation, not a bypass for those checks.
Removing a creator’s company access stops their Platform keys and new dashboard automations.
Reducing permissions narrows existing credentials on subsequent verified requests. If an
automation’s creator leaves, have an authorized owner create a replacement credential.
Increasing an app’s scope selection does not widen a token already issued. Request a new
authorization for new permissions. Disconnecting an OAuth connection revokes its grant;
reconnecting does not revive credentials issued before that revocation. Refresh tokens rotate
on use, and replaying an old refresh token can revoke the connection.
Existing members and integrations
Existing memberships without an explicit scope selection keep their legacy permissions. Saving an explicit selection replaces those defaults: an empty selection grants no company capabilities. Legacy restricted Employees retain their reporting-only OAuth limit until an authorized manager saves an explicit selection. Existing company-bound machine apps without a recorded creator retain their company binding. Older Integration, Connect, Tracking, and Scraper keys keep their separate product contracts; they are not converted into scoped Platform keys. Prefer scoped Platform keys for new Platform integrations. Existing OAuth grants with onlycontracts:write need new consent
for contracts:sign before signing contracts.
For agency credentials and direct-child precedence, follow Agency access.
For machine OAuth setup, follow Company automations.