Permissions and scopes

What each credential can do: the person it represents, the scopes per module, deletion, connected mailboxes and calendars, and an API key's special permissions.

Every request goes through three filters, in this order, and it takes only one to say no:

1The organization: the API and the MCP turned on in its workspace (otherwise 403 platform_not_enabled), an active paid subscription (on the free trial, 403 platform_requires_paid_plan) in good standing (402 payment_required), and the module active. If MB Suite has not opened them for that organization or that person, 403 platform_disabled.
2The person behind the credential: their role, their permissions in the module, the CRM permission matrix and, for a Seller with a restricted scope, only their own records. An API key can never do more than its person (403 crm_action_denied, with the action in param).
3The credential: the scopes you gave it (403 scope_insufficient), deletion (403 delete_not_allowed) and the Accounts it can reach (404 organization_not_found).

Scopes per module

Scope	What it allows
`<module>:read`	The module's reads: the `GET`s and searches.
`<module>:write`	Reads and writes. It does not include deleting.
“Allow deletions” · `<module>:delete`	Irreversible operations (delete, purge, merge), on the modules with write access. Off by default.

The reference states, for each operation, the scope it needs, the module permission, the CRM action and the roles when they apply. GET /v1/me and GET /v1/catalog return only what your credential can run.

Irreversible operations

Every operation that deletes is irreversible. Besides the deletion permission, outside the screen it needs a confirmation: dry_run → confirm_token (see Dry run and confirm_token). Most of what is deleted from MB Suite stays 30 days in the trash (each operation says whether it can be undone): the response carries its trash_item_id, and it is restored with POST /v1/trash/{item_id}/restore (owner or admin, with write access to the record's module); through the MCP, platform.trash.restore also finds it by entity_type + entity_id.

Connected mailboxes and calendars

The content of connected mailboxes and calendars (Gmail, Google Calendar, Outlook) does not go out by default. It opens with three locks, all off to begin with:

1The organization: an owner turns it on in Settings → API & MCP → API keys, “Connected mailboxes and calendars”. While it is off, those operations do not exist for any credential (404).
2The credential: the API key or the app must carry the permission (on the API key, the “Connected mailboxes and calendars” block; in OAuth, connected_content:read, which the person ticks when authorizing). Without it, 403 connected_content_not_granted.
3The data: even with both, a credential sees only the mailbox and calendar of the person who created or authorized it, and only the threads and events linked to CRM people, companies or deals. Never the whole mailbox, and never someone else's.

The affected operations carry the “Connected mailboxes and calendars” mark in the reference. The conditions for that content are in section 4a of the Terms.

Platforms with their own terms

The terms of some connected platforms limit what can be done with their data and their APIs through the MB Suite API and MCP. On the MB Suite screen they work as always. This may change if a platform authorizes a different use.

Google Ads, Google Business Profile, TikTok and YouTube: their data and changes are not available through the API or the MCP.
LinkedIn: only the reports of ad accounts and pages (structure, performance and the pages' own posts) and the Lead Gen Form responses, and only with an organization API key, through the REST API, not through the MCP or a connected app; comments, mentions and the rest of its members' content are not available, and neither is publishing, replying or changing anything on LinkedIn.

A request that breaks these rules answers 403 platform_terms_restricted: details.platform says which one and details.access what it allows (none or own_key). Through the MCP, those operations do not appear. Webhooks do not send events that carry data from these platforms.

An API key's special permissions

There are three permissions that are not scopes: owners and admins give them, on the API key, and they are off by default. For any other credential (an API key without the permission, an OAuth app and, in the Vault's case, the API key used through the MCP) vault.items.reveal_secret, ai.agents.update_live and ai.agents.create_with_key do not exist (404).

Reveal Vault passwords: the API key requests the password of the credentials chosen on the API key (up to 50, from its organization's Vault) with vault.items.reveal_secret, over REST only. It also needs the vault:read scope. The limit is 30 per hour for the person behind the API key, across all their API keys. That person must be able to use each credential. Every reveal is recorded in the credential's Activity, and so is every request for a credential outside the list or without access.
Edit live AI agents: with ai.agents.get the API key receives the agents' instructions and knowledge, and with ai.agents.update_live it edits any of them, including the ones working live in the AI Team, always with dry_run and confirm_token.
Create AI agents: with ai.agents.create_with_key the API key creates AI agents in its organization and in the Accounts it reaches, including custom versions of MB Suite's agents, always with dry_run and confirm_token. A new agent doesn't work live until someone assigns it to a seat in MB Suite.

A test API key never carries them.

Agencies and Accounts

A workspace API key reaches the Accounts you chose when creating it and that the person can see; a workspace's webhooks can listen to its Accounts. An Account's API key works only on that Account.