API keys

An API key lets something connect to one workspace without signing in. You create keys under Connect agents, at the bottom of the page. A key looks like cmcp_ followed by a long random string, and it's sent as a header:

Authorization: Bearer cmcp_...

Keys are shown once, when you create them. Copy it somewhere safe straight away. If you lose it, revoke it and make another.

Personal keys and workspace keys

When you create a key you choose whose access it has. This is the most important choice, so it's worth a minute.

A personal key acts as you. It sees what you can see and edits what you can edit, and never more than you allowed when you made it. If your access changes, the key's does too. If you leave the organization or lose access to the workspace, the key stops working. Personal keys also return your private notes, because they're yours.

Use a personal key for your own tools that can't sign in: Cursor, Claude Code with a key, a script on your laptop.

A workspace key has its own access, set when it's created, and doesn't depend on anyone's permissions. If the person who made it changes role or loses access to the workspace, the key carries on as it was. It can be given the whole workspace, or only some folders, in which case it sees nothing outside them. Workspace keys never see anyone's private notes.

When the person who made it leaves: removing someone from the organization asks who should take over the workspace keys they made. Pick anyone who could create workspace keys there (an owner, an admin, or someone who can edit the whole workspace) and the keys carry on exactly as before, now listed under that person. Or choose to revoke them instead.

Use a workspace key for things that belong to the team rather than a person: a shared n8n workflow, a production integration, an agency working on your account. Only people who can edit the whole workspace can create them.

What a key may do

Every key can read. On top of that, the same levels people have:

Can edit (saved as drafts). The key gets the editing tools over MCP and can move pages and write table rows over the REST API. Anything it writes to a page body is a draft until someone publishes it. It can delete drafts that were never published and empty folders, but not anything published. See When agents write back.

Can edit and publish. Everything above, plus publish_page over MCP and POST /pages/{page}/publish over REST, which make a draft live for every agent, and deleting published pages and folders that hold them. Publishing is a separate call from editing, so an agent still writes drafts and only publishes when it's asked to. Give this to a key only where you'd give the same person publish access: a trusted automation, or your own agent when you'd rather not open the app to publish. Only someone who can publish across the whole workspace can create a workspace key at this level.

Can change who has access to pages and folders. The key can use update_owners to give people access to pages and folders, or take it away. Leave this off unless you have a specific reason; it's rarely something an agent should be doing.

A personal key with edit access still can't edit anything you couldn't, and one with publish access publishes only what you could. A personal key without either can't edit anything, even if you could.

Limiting a key to some folders

When you create a workspace key, choose Only chosen folders and tick the folders it should see. The key can then read the pages in those folders (and everything in subfolders), and nothing else. It sees the folders above them in get_structure, so the paths make sense, but no other pages.

This is how you give an agency the brand and product folders without your pricing or internal notes, or give a support bot the help center content and nothing else.

If every folder a key was limited to is deleted, the key stops working rather than falling back to seeing everything. It's marked in the list so you can tidy it up.

Keeping track of keys

The key list shows each key's name, its first few characters, whose it is (Workspace, held by the person who made it or took it over, or Acts as and a name for a personal key), what it can do, which folders it's limited to, and when it was last used. Name keys after where they're used ("n8n onboarding flow", "Northwind agency", "Cursor, Priya's laptop") so you can tell them apart in a year's time.

You see every key if you can edit the whole workspace. Otherwise you see only your own personal keys.

Revoking a key

Press Revoke next to a key. It stops working on the next request; there's no grace period.

• Organization owners and admins can revoke any key.
• People who can edit the whole workspace can revoke its workspace keys.
• Everyone can revoke their own personal keys.

When someone is removed from the organization, their personal keys are revoked at once, so nobody has to go looking for them. Their workspace keys go to whoever the person removing them picks, or are revoked if they'd rather.

Giving a key to someone outside the company

This is one of the main things keys are for. A sensible setup for an agency or contractor:

1. Create a workspace key, so its access doesn't depend on whoever set it up.
2. Limit it to the folders they need, if that's not everything.
3. Leave it read only, unless you want them suggesting edits; Can edit keeps those as drafts for you to publish.
4. Name it after them.
5. Send them the workspace URL and the key, and point them at Connecting your tools.

When the work ends, revoke it. Their agent loses access on its next request.

Keeping keys safe

Treat a key like a password. Don't paste it into shared docs, chat channels or project files that get committed. If a key might have leaked, revoke it; making a new one takes seconds.

Each workspace is also limited to 120 retrieval requests a minute across all its keys and connections, which caps what a leaked key could run up before you notice. See Limits and formats.