Skip to main content
An Attensira API key authenticates a program — an MCP client, a script, an agent — as your organisation. You mint it in the app, copy it once, and send it as a bearer token. A key names one workspace as its default, and every tool and endpoint takes an optional project to reach any of the others. One key reaches both programmatic surfaces: the MCP server and the REST API. You do not need a second credential to add the other, and that has not changed — the MCP server accepts keys permanently, alongside OAuth.

​
When a key, and when OAuth

The MCP server takes either. The REST API takes a key only. Use a key when nothing can open a browser: an n8n workflow that fires at 3am, a CI job, a scheduled script, a server-side agent, anything calling the REST API. Keys do not expire, so unattended work keeps running without anyone re-approving it. Use OAuth when a human is present at first connect — Claude, Claude Code, Cursor, VS Code, ChatGPT. It is nicer there for three reasons: no secret ever lands in a config file you might commit, access tokens are short-lived so a stolen one is worth little, and each client is its own connection you can remove without breaking the rest. Use a key when nothing can open a browser, or when you need access you can cut off instantly: a revoked key stops working on the very next request, while a token already issued survives until it expires. Neither is deprecated and there is no cutover. See Connect a client for both paths and Connections for managing OAuth grants.

​
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. There is no equivalent split over OAuth: a signed-in connection always carries read and write, so a key is the only credential that can be made read-only. See the tool reference for which tools need write, and REST API authentication for the equivalent over HTTP.
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. Both the MCP server and the REST API check the token against ^atn_live_[0-9a-fA-F]{32}$ before making any upstream call, so a truncated paste or a stray space fails immediately with a 401 carrying WWW-Authenticate: Bearer. The MCP server answers in the OAuth error shape, which is the same for a malformed key and an unusable OAuth token:
MCP 401
The REST API answers in its standard error envelope:
REST 401
That shape check is not authentication. Whichever surface you use, the token is forwarded to Attensira, which owns the real validation — hash lookup, revocation, expiry, scopes and rate limiting. 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. OAuth connections are revoked elsewhere — Settings > Connections, described in Connected applications — and revoking a key never touches them. 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, every workspace in the organisation

A key belongs to your organisation and names one workspace as its default. Every MCP tool takes an optional project, and every REST endpoint an optional ?project=, so a single key reaches every workspace in the organisation — running three domains does not mean minting three keys. Omit it and the default is used. An OAuth connection works the same way, and reaches the same set. What cannot be widened is the organisation. A workspace outside it is a 404, the same answer as one that never existed, and no scope or setting changes that. get_account lists what a credential can actually reach. Next: Connect over MCP, or the REST API if your own code is doing the work.