Skip to main content
Two ways in, for two kinds of caller: an API key for your own code, and OAuth for an agent you connect from an MCP client. Every /v1/* endpoint accepts either — one per request, never both.

​
API keys

  • Created and revoked from the dashboard API Keys page
  • Owned by your Account (billing tenant)
  • Up to 5 active keys per Account
  • Stored hashed server-side — the full secret is shown only at creation
Treat API keys like passwords. Do not commit them to git or expose them in client-side code.
Sign-in (Google or sign-in link) is only required to access the dashboard and manage keys — not for machine-to-machine calls.

​
OAuth for MCP clients

An agent is not a machine you own. It runs somewhere else, it acts on your behalf, and handing it a key would give it everything your key can do, for as long as the key lives. So the remote MCP server does not take one. Instead it speaks OAuth 2.1 with PKCE. Adding the connector sends you to the sign-in server once; you choose what the agent may do, and it receives a token bound to that choice — good for an hour, refreshed silently, and revocable from Settings → API keys → Connected agents. A call the agent was not granted comes back refused, naming the missing permission. Nothing is charged for it. Both credentials are metered the same way and land in the same Spend log — a key’s calls under the key’s name, an agent’s under the agent’s. That is how you tell them apart after the fact.
This flow is discovered automatically: the server publishes its metadata and an unauthenticated call answers 401 with a WWW-Authenticate header pointing at it. There is nothing to configure beyond the server URL.