Skip to main content
fetchbean authenticates every request with your fb_ API key, passed in the X-API-Key header. There are no per-provider credentials to manage — one key covers every provider and endpoint available through the gateway.

​
Sending your key

Include your key in the X-API-Key header of every request:
API keys are not accepted through the Authorization header. That header is reserved for the Firebase session token used by dashboard-only routes such as Connections. Sending Authorization: Bearer fb_… returns 401 invalid_token.
Here’s a complete example:

​
Managing keys

Create and revoke keys from API Keys in the dashboard. Keep these rules in mind as you manage them:
  • Keys are shown once. At creation, copy your key immediately — fetchbean only ever stores a hash, so it cannot be recovered or displayed again.
  • Use one key per app or environment. Separate keys for production, staging, and development mean you can revoke one without disrupting the others.
  • Revocation is instant. As soon as you revoke a key, all requests using it return 401. There is no grace period.

​
Securing your key

Never commit an API key to source control or embed it in client-side code. Anyone who obtains your key can make billable calls on your account. If a key is exposed, revoke it immediately from the dashboard and issue a new one.
Store your key as an environment variable and read it at runtime:
Reference it in your code without hard-coding the value:

​
Authentication errors

A missing or invalid key returns HTTP 401 with a typed error body:
The billable: false field confirms that authentication failures are never charged to your account. If you see a 401, check that you copied the full key correctly and that the key hasn’t been revoked.
When using fetchbean with an MCP server, your key is configured once in the server settings — the agent itself never needs to handle it directly. See the MCP guide for setup instructions.