API keys
Personal access tokens (PATs) authenticate every request to the Ritual MCP server. The CLI mints one for you automatically during ritual init; you can also create them manually from your account settings.
Where PATs come from
| Source | When |
|---|---|
ritual init (CLI) | Auto-minted on first run. Named Ritual CLI — <hostname>. Stored at ~/.config/ritual/credentials.json and registered as the Bearer token in each coding agent’s MCP config. |
| Manual creation | https://app.ritualapp.cloud/settings/tokens → Create token. Use when you’re building your own MCP client, or scripting against the API outside the CLI. |
Most users never need to create a PAT manually — ritual init handles it.
Format
PATs are issued as ritual_pat_… (followed by ~32 base32 characters). They’re long-lived (~1 year by default) and tied to your user account, scoped to the workspaces you have access to.
Treat them like passwords — they grant the same access you have in the web UI.
Create a PAT manually
- Sign in to app.ritualapp.cloud
- Open Settings → Tokens (also reachable via your profile menu → API tokens)
- Click Create token
- Name it after the surface it’ll live on (e.g.
cursor-on-laptop,ci-pipeline) - Copy the token immediately — it is not shown again
Use a PAT
Pass as a Bearer token in the Authorization header on every request to the MCP server:
POST /mcp HTTP/1.1
Host: mcp.ritualapp.cloud
Authorization: Bearer ritual_pat_…
Content-Type: application/json
Accept: application/json, text/event-stream
See the MCP server reference for the full transport details.
Rotate or revoke
In Settings → Tokens:
- Revoke an existing token to invalidate it immediately. In-flight requests using it will start failing on the next call.
- Create a new token with the same name + scope, update the consuming surface (CLI: re-run
ritual init; manual integration: update the Bearer header), then revoke the old one.
Plan rotations during low-traffic windows — there’s no overlap period where both tokens are valid against the same agent connection.
Storage rules
- Never commit PATs to git. The CLI stores yours at
~/.config/ritual/credentials.jsonwith 0o600 permissions (owner read/write only). - Never paste PATs into chat, screenshots, or shared documents. If a PAT leaks, revoke it immediately, then mint a new one.
- Don’t share PATs across people. Each PAT is tied to a single user account; an action taken with someone else’s PAT shows up as their action in the audit log.
- CI / shared infrastructure: create a service-account user, mint that account’s PAT, store in your secrets manager. Don’t use a human user’s PAT for shared CI.
Scopes
Today PATs inherit the full set of permissions of the issuing user (same access you have in the web UI). Per-token scope restrictions (read-only, write-only, single-workspace) are on the roadmap.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
401 Unauthorized | Wrong / revoked PAT, or missing the Bearer prefix | Verify the Authorization header is exactly Bearer ritual_pat_… (note the space). Confirm the PAT hasn’t been revoked. |
403 Forbidden | PAT is valid but doesn’t have access to the requested workspace | Sign in to the web UI as the same account and confirm you can see the workspace there. |
406 Not Acceptable | Client didn’t send the dual Accept: application/json, text/event-stream header MCP Streamable HTTP requires | See MCP server FAQ — the spec requires both Accept types. |
Related
- CLI —
ritual initmints PATs automatically - MCP server — endpoint + transport details
- Security & Privacy — how Ritual handles credentials at rest