Authentication

Two authentication methods are available. The appropriate one depends on the client being built.

Access tokens

For scripts and self-hosted services. Create a token under Settings → Integrations, grant the narrowest permissions sufficient for the task, and send it as a bearer token.

The token is displayed once. Only a hash is stored, together with an eight-character prefix for identification in the list. A lost token must be replaced.

Tokens expire. An expiry date is required at creation; permanent tokens are not available.

Note the asymmetry: over REST a token is read-only, and every non-GET request is refused. See what an external client can reach.

OAuth, for MCP clients

An AI agent does not use a manually supplied token; it discovers the authentication endpoint.

The flow follows the MCP authorization spec, which builds on RFC 9728 protected resource metadata:

1. The client calls the MCP endpoint with no credential and receives 401.
2. The response points it at a metadata document describing where to authenticate.
3. The client reads that document, runs the OAuth flow against the authorisation server it names, and retries with the token it obtains.

Two discovery paths are served, because clients probe both forms:

/.well-known/oauth-protected-resource	Origin-wide
/.well-known/oauth-protected-resource/v1/mcp	Path-suffixed, per RFC 9728 §3.1

Both are unauthenticated by design: the client holds no credential at that stage, which is the purpose of the document.

The metadata must be reachable and correct, or the client fails silently

A client that cannot retrieve this document, or that finds within it a URL not matching the resource it called, discards the document per the specification and fails to connect. No error is produced on either side. Where an agent fails to connect and nothing is logged, retrieve these two URLs directly and verify the origin they advertise.

Access tokensSettings → Integrations