Skip to main content
Personal API keys authenticate a user. MCP accepts personal keys only, for hosted HTTP and local stdio. Create one named key per client, such as Codex — staging or Claude — support. A key stores explicit operation scopes and a snapshot of selected teams/projects. Every request also evaluates the owner’s current membership, role, and capabilities. Removing a membership or changing a role limits access immediately; new memberships and projects are never added automatically.

​
Create a personal API key

  1. Open the user menu and select Personal API Keys.
  2. Click Create Personal Key and name the client.
  3. Start with Read only, which selects resources.read and diagnostics.read.
  4. Select current projects. All current teams and projects saves their current IDs; it is not an ongoing wildcard.
  5. Keep the default 90 days, or choose another expiration.
  6. Confirm your current password and copy the secret. It is shown only once.
Secrets start with sr_user_. Store them in client credential configuration or a secret manager. Revoke exposed keys.

​
Edit access

Use Edit access on an active key to change its name, operations, project grants, or expiration without rotating its secret. Expired or revoked keys cannot be reactivated; create a replacement for the client. Read only, Prepare drafts, and Push testing presets provide starting points; review the individual operations before saving. Adding scopes/projects or extending expiration requires your current password. Narrowing access does not. Concurrent edits are checked against the saved grant version; refresh and review again if another edit wins. Revocation takes effect immediately. Grants are bound to the membership through which they were issued. Leaving and rejoining a team does not automatically reactivate an old grant. Use Refresh current grants to retain only selected projects you can access now and bind them to your current memberships, then confirm your password and save. The all-current snapshot option also requires confirmation when it regrants a changed membership. The original personal-key migration assigns only the twelve operation scopes defined by MCP 0.2.0. Later scopes, including imports and live delivery, are opt-in. Existing personal keys migrate to those original operation scopes and a snapshot of projects the owner can access at migration time. Their familiar credential remains valid, and later projects are not added. Review migrated keys and narrow access to the clients’ actual tasks. Keys do not store a default team or project.

​
Connect MCP

Discover account, teams, and projects through MCP. Pass an explicit project_id on project tools. MCP does not select a project from a header, environment variable, or the currently open dashboard. See Dashboard MCP for scopes, schemas, sandbox testing, and handoffs.

​
Discover account access through the API

Account discovery returns credential status, operation scopes, grant version, and grant_summary team/project counts rather than full grant arrays. Use the paginated team and team-project discovery endpoints to select IDs; follow metadata.next with after while has_more is true. Discovery is limited to stored grants intersected with current access. Project responses identify effective roles/capabilities so clients can explain which actions are available. Full saved grants remain visible to the signed-in owner in Personal API Keys.

​
Credential boundaries

  • Integration keys continue authenticating regular APIs, SDKs, and SMTP. MCP rejects them.
  • Personal credentials are never embedded in browser or mobile application code.
  • Logging out or resetting your password does not revoke personal keys.
  • Expired, revoked, banned-account, and deleted-account credentials cannot authenticate.
  • OAuth connection flows are deferred; use a personal key for MCP.

​
Access created by a key

Owners can opt into access to teams/projects created by that particular key. The policy is disabled by default and requires owner password confirmation to enable. Creation still requires its own operation scope and current role. It never grants access to unrelated resources. Keys cannot edit their scopes or creator-access policy. Team-only grants permit authorized administration without granting any project access. New data operations use separate opt-in scopes: imports.write, exports.read, audiences.delete, topics.delete, and suppressions.write. Imports do not imply deletion, export, or permission to remove delivery suppressions. Messaging authoring/publication scopes are also independent. Availability depends on deployment rollout flags and current role capabilities; selecting a scope does not bypass either.

​
Manage keys through MCP

When administration is enabled, the separate personal_keys.manage scope permits listing, creating, editing and revoking your own personal keys with personal_keys_list, personal_keys_create, personal_keys_update and personal_keys_revoke. Creating a key still requires your current password. Widening access or extending expiration retains password verification and expected_grant_version checks. Password inputs are write-only and generated key values are returned once, without operation-receipt copies. Existing keys receive no new scope automatically. Integration keys use integration_keys_* with the selected project_id, integration_keys.write, and your current key-management role. A personal key cannot delegate access beyond its explicit project grants or to future projects.