Scopes & permissions
A scope is the unit of consent you grant on the OAuth consent screen when connecting an assistant. Every tool call a connected assistant makes is checked against the scopes baked into its access token — not against a fresh read of your account role — so what you approve at connect time is exactly what stays approved until you revoke it or reconnect with a different selection.
The full list
| Scope | What it allows | Granted by default? |
|---|---|---|
projects:read | See your email projects and their designs | Yes |
projects:write | Create and edit email projects | Yes |
contacts:read | See your contact lists — summaries always; individual contact rows only when a tool explicitly asks for them | Yes |
contacts:write | Add and update contacts, manage unsubscribes | Yes |
analytics:read | See campaign results, form responses and orders | Yes |
campaigns:read | See send history and recurring schedules | Yes |
campaigns:send | Send campaigns to your contacts, and create/enable recurring schedules | No — opt-in only |
templates:read | Use your saved and community templates | Yes |
templates:write | Save a project as a template | Yes |
mailbox:read | Read mail received at your verified domain, and support tickets | Yes |
mailbox:write | Reply to mailbox threads and support tickets | Yes |
commerce:write | Mark a physical product order fulfilled | Yes |
journeys:read | See your automated journeys and saved segments | Yes |
journeys:write | Build journeys (always saved turned off), create segments, and pause journeys. Turning a journey on also needs campaigns:send | Yes |
openid | Confirm your identity | Yes |
email | Share your account email address (used for workspace domain restrictions on platforms that support them) | Yes |
offline_access | Stay connected without re-authorizing every hour | Yes |
Why campaigns:send is different
Every other scope here is either read-only or an edit you can undo (delete the block, remove the contact, restore the template). Sending mail to real people is the one action a connector can take that can't be taken back. That's why the consent screen leaves it unchecked by default, shows it with a distinct warning color, and — even once granted — still requires the two-step prepare_send/confirm_send flow described in Security before anything actually goes out.
How your account role limits scopes
If you're a viewer on the account you're connecting as, the consent screen only offers *:read scopes plus openid/email/offline_access — the same read-only ceiling a viewer already has everywhere else in MailInApp. Editors and owners can grant the full list; the one thing neither can grant is anything a connector doesn't expose at all — credential rotation, SMTP/payments/domain settings, and team management stay unreachable from any connector tool, regardless of scope, mirroring the existing editor carve-outs elsewhere in the product.
Which account a connection acts as
A connection is scoped to one account for its whole lifetime. If you belong to more than one company — your own personal account, plus any team you're an active member of — the consent screen asks you to pick one before showing you scopes. Working across two companies from the same assistant means connecting twice, which also gives you two independently revocable entries on the Connections page.
That account binding is re-checked on every single tool call, not just at connect time: if a team owner removes you as a teammate, or your role changes, the next call from that connection reflects your current standing — never the standing you had when you granted the scopes.