> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sendrealm.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Personal API Keys

> Create scoped personal credentials for MCP clients and account discovery

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

```text theme={null}
https://mcp.sendrealm.com/mcp
Authorization: Bearer YOUR_PERSONAL_API_KEY
```

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](https://docs.sendrealm.com/agent-skills/dashboard.md) for scopes, schemas, sandbox testing, and handoffs.

## Discover account access through the API

```bash theme={null}
curl https://api.sendrealm.com/me \
  -H "Authorization: Bearer $SENDREALM_PERSONAL_API_KEY"

curl https://api.sendrealm.com/teams \
  -H "Authorization: Bearer $SENDREALM_PERSONAL_API_KEY"

curl https://api.sendrealm.com/teams/TEAM_ID/projects \
  -H "Authorization: Bearer $SENDREALM_PERSONAL_API_KEY"
```

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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.