Authentication
The two credentials every Fleeex call carries — your app API key and the end-user id you vouch for.
Every call the SDK makes carries two pieces of identity. Getting them right is what makes metering correct and per-user.
| Credential | SDK option | Sent as | Identifies |
|---|---|---|---|
| API key | apiKey | Authorization: Bearer <key> | Your app. |
| End-user id | userId | x-fleeex-user: <id> | The end user the call is for. |
const client = new FleeexClient({
apiKey: process.env.FLEEEX_API_KEY!, // flx_…
userId: "user-123",
});The API key (flx_…)
- It authenticates your app. Issue and rotate keys from your Fleeex account (the dashboard / control plane).
- It's a server-side secret. A leaked key impersonates your app — never ship it in a browser, mobile bundle, or public repo. Keep it in an environment variable or a secrets manager.
The user id (x-fleeex-user)
- This is your own identifier for the end user — whatever your app already uses. Fleeex trusts your app for its own users' identity; the id never crosses your app boundary.
- It's what makes usage and billing per user: each
(app, user)pair maps to a wallet identity.
One FleeexClient is bound to one userId. Handling many users? Create a client
per user (they're cheap), or set the header per request with the raw OpenAI SDK (see
Drop back to raw OpenAI).
Control plane vs. data plane
The SDK operates on the data plane — proxied AI calls and read-only billing helpers, authenticated by the app API key. Managing the account itself — funding the wallet, creating apps, issuing keys — is a separate control plane (the dashboard), so an app key can spend against a wallet but can never top it up or mint new keys.
Next
- Quickstart — make a call.
- Balance & payments — read the balance and handle
the
402top-up flow.