Authentication and keys
How to send your API key, how keys are stored, and what happens when a key is revoked or a plan ends.
Every request carries your key as a Bearer token, for REST and MCP alike:
Authorization: Bearer fbt_EXAMPLE_not_a_real_key_0000Managing keys
- Create and revoke keys in API keys. You can have up to 20 active keys, so use one per application.
- A key is shown once, when it is created. We keep only a hash and cannot show it again: if you lose it, revoke it and create another.
- The page shows when each key was last used and its requests per day.
Keeping a key safe
- Keep keys on your server or in your MCP client's settings. Never put one in a web page or a public repository: the REST API does not allow calls from browsers on other sites.
- Never put a key in a URL. Only the
Authorizationheader is read. - If a key may have leaked, revoke it. It stops working on the next request.
When access stops
Keys are checked on every request, with nothing cached:
- Revoked key:
401 invalid_api_key. - Plan without the API, including when a subscription ends:
403 plan_without_api. Your keys come back to life if you subscribe again. - Suspended account:
403 suspended.
Versioning
The version is in the path, /api/v1, and every response carries X-API-Version: 1. Within v1 we only add things, such as new fields and new endpoints, so ignore fields you do not know. Changes are listed in the changelog.