Settings → API Keys — “Manage API access keys for programmatic access”.
Creating a key
Click to open Create API Key, give it a name — “e.g. Production, CI/CD” — and create it. The confirmation reads “API key created”.
Name keys after where they’re used. When you later need to revoke one, the name is all you have to work out what will break.
The full key is shown once, immediately after creation. Copy it before leaving the screen. Afterwards the list shows only the prefix (smx_xxxxxxxx...****) and the key cannot be retrieved — you’d have to create a new one.
Using the key
Send it in the X-API-Key header against the REST API:
That’s what keys are for. See API authentication.
The MCP snippets on this screen don’t work
The creation screen shows three copy-able snippets: a claude mcp add command, an mcpServers JSON block, and a curl example. Only the curl one is correct.
Both MCP snippets configure an X-API-Key header, and the MCP server rejects API keys. Using them produces a 401: “This endpoint uses OAuth, not API keys. API keys authenticate the REST API at /v1.”The MCP endpoint uses OAuth and needs no credential in your config at all. Follow Connect the MCP server instead. What a key can do
A key authenticates as the organization, not as the person who created it. It carries the organization’s access to every project, and it isn’t limited by the creating member’s role.
Any member can create a key, and a key created by a member has the same reach as one created by the owner. Treat keys as organization-level credentials: store them in a secrets manager, never commit them, and review the key list periodically. One key per use
Create a separate key for each consumer — your CI pipeline, a scheduled job, a production integration. It costs nothing and means you can revoke one without taking down everything else.
AI clients don’t need a key at all; they authenticate through OAuth.
