Authentication

API keys

Hosted requests are authenticated with a secret key that starts with fw_live_. Mint and manage keys on the Account page. A key is shown in full exactly once, at creation — store it somewhere safe right away, because only its prefix is shown afterward.

Using a key

Pass the key as a bearer token in the Authorization header on every request:

Authorization: Bearer fw_live_xxxxxxxxxxxxxxxxxxxx

A complete request:

curl https://flywheel.opspot.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $FLYWHEEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "fitness", "messages": [{ "role": "user", "content": "Hi" }] }'

Requests without a valid key return 401 invalid_api_key. See Errors & rate limits for the full list.

Rotation & revocation

You can mint multiple keys and revoke any of them independently from the Account page — useful for rotating credentials or giving each environment (staging, production) its own key. Revoking a key takes effect immediately; in-flight requests with that key stop authenticating.

Best practices

• Keep keys server-side. Inject them from a secret manager or environment variable, never the client.
• One key per environment. Separate keys make rotation and incident response surgical.
• Rotate on exposure. If a key may have leaked, revoke it and mint a new one — there’s no penalty for rotating.
• Self-host for zero keys. If you run the open weights, there is no hosted key and no usage leaves your network — see Self-hosting.