Authentication & permissions
Give each integration exactly the account and mailbox access it needs.
API credentials
Create an account-bound REST key in Integrations. Send it in the Authorization header on every request.
Authorization: Bearer your-cm_rest_-credentialSecrets are shown once and stored as hashes. Keep keys on your server. Use separate credentials for separate applications so you can rotate or revoke one integration independently.
Choose permissions independently
| Permission | Allows |
|---|---|
read | Account and resource metadata; email reads for granted mailboxes. |
write | Resource changes, drafts, folders, flags, and message organization. |
send | Email submission, replies, and forwarding. |
delete | Resource and message deletion, subject to deletion safeguards. |
webhook | Webhook subscription and delivery management for account owners and admins. |
Permissions are independent. Having write does not imply send or delete. Account resource changes require an owner or admin.
Authorize mailbox access
Account membership alone never grants access to email content. Mailbox access requires both a current grant and that mailbox selected on the credential.
- Prove access with a single-use verification code delivered to the mailbox, or receive an explicit grant from the account owner.
- Select that mailbox when creating the credential.
- Choose the permissions the integration needs for that mailbox.
Expiry, rotation & revocation
Set an expiry when issuing a credential. Rotate keys in Integrations and update the secret in your application. Revoking a credential takes effect immediately on subsequent requests.
Removing membership or revoking a mailbox grant invalidates dependent access, including webhook deliveries. MCP uses OAuth tokens or a purpose-bound MCP key; an MCP credential cannot call the REST API to bypass approval.