Skip to main content
An Attensira API key authenticates a program — an MCP client, a script, an agent — as one workspace. You mint it in the app, copy it once, and send it as a bearer token. A key is bound to a single workspace, so no tool or endpoint asks you which workspace you mean: the key already says.

​
Mint a key

1

Open Settings > Developer

Go to app.attensira.com/settings/developer in the workspace the key should belong to. If you work across several workspaces, check the workspace name before you continue — the key you mint here cannot be moved to another one later.
2

Name the key

Give it a name that says where it will run, such as claude-desktop-laptop or ci-nightly-report. The name is the only thing you will see in the list afterwards, so a vague name makes revoking the right key harder.
3

Choose the scope

Pick read, or read and write. See below for what each allows.
4

Copy the key immediately

The full key is shown once, on this screen, and never again. Paste it into your password manager or your client’s configuration before you navigate away.

​
Choosing a scope

Read lets a key retrieve what already exists: metrics, prompts, pages, sessions, account details, and the list of automations. It cannot change anything in the workspace. Read and write adds the actions that alter state or spend credits: adding prompts and competitors, creating and running automations, removing prompts, deleting automations, and asking the agent. Give a key the narrower scope unless it needs the wider one. A dashboard, a reporting script, or a read-only agent integration should be read-only — then a leaked key cannot delete an automation or burn credits. See Connect over MCP for which tools each scope reaches.
remove_prompt and delete_automation are destructive and are reachable with a read-and-write key. There is no separate confirmation step at the API level.

​
The key format

A key looks like this:
That is the prefix atn_live_ followed by exactly 32 hexadecimal characters. The MCP server validates the token against ^atn_live_[0-9a-fA-F]{32}$ before it makes any upstream call, so a truncated paste or a stray space fails immediately with:
Send it as a bearer token:

​
Why you only see it once

We store a hash of your key, not the key. When a request arrives, we hash the token you sent and compare hashes. That means the plaintext value exists in our systems only during the moment you mint it. The consequence is not a policy choice you can appeal: we cannot show you the key again, and we cannot recover it for you. If you lose it, no one at Attensira can read it back. Revoke the lost key and mint a new one.
Before closing the reveal screen, paste the key somewhere durable and confirm you can read it back. That is the only opportunity.

​
Revoking a key

Revoke from the same Settings > Developer screen. Revocation takes effect for new requests; anything already using that key starts failing authentication. Nothing else in the workspace changes — data collected through the key stays, and automations it created keep running on their schedules. Revoke when someone leaves, when a key has been pasted anywhere it should not have been, when a machine is decommissioned, or whenever you cannot say with confidence where a key is stored. Minting a replacement costs nothing, so rotate rather than wonder.

​
One key, one workspace

A key names its workspace. No MCP tool accepts a workspace id, and there is no way to widen a key’s reach after minting. To work across several workspaces, mint one key per workspace and configure your client with the right one for each. Next: Connect over MCP.