Authentication
Create an API key, send it as a Bearer token, and understand key scopes
Every REST API request carries a credential in the Authorization header. For
programmatic access that credential is a Closedloop API key, which starts with
sk_live_.
curl https://api.closedloop.ai/me \
-H "Authorization: Bearer sk_live_your_api_key_here"Create an API key
- In the web app or the Desktop app, open Settings.
- Under Labs, choose API Keys.
- Choose Create key and give the key a name.
- Copy the secret. It is shown once, when you create it; after that only the key's metadata is listed.
A key belongs to the user who created it and to that user's organization. Requests made with it act as that user, inside that organization only: there is no request parameter that switches a key to another organization. You revoke a key from the same API Keys panel.
The same key is the credential the MCP server asks for when a client connects.
Managing keys is itself a signed-in operation. GET /api-keys, POST /api-keys,
and DELETE /api-keys/{id} accept only a signed-in Closedloop session, so an API
key cannot create, list, or revoke API keys.
How a request is authenticated
The API reads the token after Bearer and routes on it:
| Token | Treated as |
|---|---|
Starts with sk_live_ | An API key. It is looked up and must not be revoked or expired. |
| Anything else | A signed-in Closedloop session token (the web and Desktop apps' own credential). |
An API key request is refused with 401 when the key is unknown, revoked, or
expired, when the user it belongs to is no longer active, or when its
organization no longer exists. The body is the standard error envelope:
{ "success": false, "error": "Unauthorized" }A key whose stored scope set is empty or unrecognizable is refused rather than treated as full access; reissue it.
Scopes
An API key carries one or more scopes. Keys created today receive all three:
read, write, and delete. Older read-only keys still authenticate, but the
API no longer issues them.
Each endpoint requires a scope. Unless the endpoint declares its own, the requirement follows the HTTP method:
| Method | Scope required |
|---|---|
GET, HEAD | read |
DELETE | delete |
POST, PUT, PATCH | write |
Some endpoints declare a different requirement explicitly; that requirement
replaces the method default. A key that lacks the required scope gets 403:
{ "success": false, "error": "Forbidden" }Scopes apply to API keys only. A signed-in session is not scope-checked; what a session may do is decided by the endpoint's own permission rules.
Which endpoints take a key
Most endpoints accept either an API key or a signed-in session. A few accept only a session and refuse a key, such as the API key management routes above. Each endpoint page in this reference lists the credentials it takes under its security requirements, so check the page rather than assuming a key works everywhere.