API keys

An Operator API key belongs to the board, not to the person who created it. Each key holds the permissions you choose when you create it, and those permissions don’t change afterwards. A key keeps working when its creator changes role or leaves the board; revoke the key to stop it.

Choose permissions

Create keys in Settings → Developer → API keys and select only the permissions the client needs. Most areas have levels, and each level includes the one below it:

• publish includes manage and read. For example, jobs.publish can also edit and read jobs.
• manage includes read. For example, jobs.manage can also list and read jobs.
• read grants read access only.

A level never grants a different area: settings.manage does not include settings.integrations.read. Permissions without levels, such as members.self, apply exactly as named.

Builder access

The Builder: read, Builder: manage, and Builder: publish permissions let a local coding agent work on the board’s Builder source through the Cavuno CLI or the /builder MCP endpoint:

• builder.read checks out an existing draft and reads its status and previews.
• builder.manage also creates drafts and submits source changes.
• builder.publish also shares drafts and publishes versions. Every publish still runs Cavuno’s preview and Go live checks.

Creating drafts, submitting, and publishing also need a paid plan with API access. Builder access works on any board with the AI website builder turned on. For the full workflow, see Use your own coding agent.

Keep keys out of MCP

MCP can’t create API keys, list them, or recover a key’s plaintext secret. Copy the plaintext value when Cavuno shows it after creation. Store it in the MCP client’s credential store or a secret manager, never in a prompt or repository.

To rotate a key, create the replacement with the same permissions, update the client, confirm it still authenticates, then revoke the old key in the dashboard.