Authentication

The MCP endpoint accepts the same three schemes as the REST surface — see Flux API Authentication for the full mechanics of each. An MCP integration turns on two narrower questions: which scheme the client is able to send, and how quickly access can be withdrawn.


Which scheme

Pick by what the client lets you send, not by how sensitive the content is:

SituationScheme
Hosted connector that can only send Authorization: BearerBearer fxk_…
Your own client or server-side integrationSimple or Secure
Public contentno header at all

A hosted connector — the Claude API's mcp_servers[].authorization_token, and hosted connectors generally — takes a single token field and always sends it as Authorization: Bearer <token>. There is no way to make it send Simple or Secure instead, so those connectors need a bearer token or nothing works. A client where you write the header yourself (Claude Code, Cursor, custom code) can send Simple; server-side code that can sign each request should prefer Secure. Public APIs need no header at all — is_auth_required: false accepts anonymous reads.

For the step-by-step of wiring either path into a client, see Connect Claude and Connect ChatGPT and OpenAI.


Bearer tokens

A bearer token is an opaque fxk_ credential bound to an existing Flux API key — not a separate identity. It is:

  • 47 characters, and contains no :, so it can never be mistaken for a public:private pair.
  • Shown once, at issue — only a hash is stored afterward, the same contract secret_key already has.
  • Exactly as powerful as the key it's bound to. It grants nothing extra and restricts nothing; role, grants, and per-collection allowed_methods all resolve through the key.

Issuing and revoking bearer tokens are Management API calls — see Flux API Keys → Bearer token for the endpoints and request/response bodies.


Revocation timing

Three ways to cut off access, with three different speeds:

deleting the key            took effect after 305 s
emptying the key's role     took effect after 284 s
revoking a bearer token     took effect on the next request

Deleting a key or stripping its role changes a permission snapshot that is cached for roughly 5 minutes — the figures above are that cache expiring. Revoking a bearer token skips the cache entirely: the token itself stops resolving, so the very next request fails.

Revoking or re-issuing a bearer token leaves public_key, secret_key and role untouched, so it can be done without disturbing anything else built on that key.


What the 401 messages mean

Three distinct strings, each pointing at a different mistake:

  • Name
    Invalid authentication method
    Description

    The scheme itself is not recognised — for example Authorization: Basic .... Send Simple, Secure, or Bearer.

  • Name
    Unsupported bearer token
    Description

    Bearer was accepted as a scheme, but the token doesn't have the fxk_ prefix — for example a Management API JWT was sent where a Flux bearer token belongs.

  • Name
    Invalid API key
    Description

    The prefix is right, but the credential itself is rejected — wrong, revoked, or unknown.

See Flux API Authentication → Error Responses for the full error payload shape.

Was this page helpful?