Permissions
What are Permissions?
Permissions let you restrict what an API key can do. By default, an API key has full access within its scope (organization, pod, or inbox). When you provide a permissions object, it acts as a whitelist: only the permissions you explicitly set to true are granted. Everything else is denied.
This gives you fine-grained control over which resources and operations each key can access, on top of the existing scope-based isolation provided by pod-scoped and inbox-scoped keys.
How Permissions Work
Whitelist model
When you create an API key with a permissions object, it switches from “full access” mode to “whitelist” mode:
- No
permissionsfield: The key has full access within its scope. This is the default and is backward compatible with existing keys. permissionspresent: Only permissions set totrueare allowed. Any permission that is omitted or set tofalseis denied.
Backward compatibility
Existing API keys without a permissions field continue to work exactly as before with full access. The whitelist only activates when you explicitly provide the permissions object.
Intersection with scope
Permissions are intersected with the key’s scope. A key scoped to a single inbox cannot gain organization-level capabilities (like create_inbox or create_domain) even if those permissions are set to true. The effective permissions are always the intersection of what the scope allows and what the permissions object grants.
Privilege escalation protection
A restricted API key cannot create a child key with more permissions than itself. When creating a new key, the child’s permissions are automatically constrained to the parent’s effective permissions. This prevents privilege escalation through key creation.
Permissions Reference
Inboxes
Threads
Messages
Content Filtering
When a content filtering permission is denied, items with that label are automatically excluded from list results and return “not found” on direct access. For example, setting read_spam to false means the key will never see spam messages in any listing or lookup.
Drafts
Webhooks
Domains
Lists
Metrics
API Keys
Pods
Code Examples
Read-only key
Create an API key that can read all resources but cannot create, update, or delete anything.
No-spam key
Create a key with full access but block visibility into spam, blocked, and trash content. This is useful for agent-facing keys where you want to prevent the agent from processing unwanted email.
Copy for Cursor / Claude
Copy one of the blocks below into Cursor or Claude for complete Permissions API knowledge in one shot.
Best Practices
- Use the principle of least privilege. Only grant the permissions your agent actually needs. A support agent that reads and replies to emails does not need
create_domainordelete_inbox. - Combine with scopes for defense in depth. Pair permissions with pod-scoped or inbox-scoped keys. Scopes limit which resources a key can see, while permissions limit what it can do.
- Filter unwanted content from agents. Set
read_spam,read_blocked, andread_trashtofalseon agent-facing keys. This prevents agents from seeing or processing unwanted email, keeping their context clean.
