Skip to main content
Rafflesia accepts one credential type on the wire: a bearer token in the Authorization header. That token is either an API key (for scripts, agents, and CI) or a session credential minted by interactive login.

​
Interactive login

This opens AuthKit in a browser, completes the exchange on a loopback callback, and stores the credential locally. Useful flags: Check and clear it with:

​
API keys

Create keys in the dashboard. A key looks like sk_<environment>_<secret> — the environment slug is part of the prefix, so a staging key is visibly not a production key. The secret is shown once at creation; only its prefix and hash are stored.
Or per invocation:
Prefer RAFFLESIA_API_KEY over --api-key in shared environments — a flag value lands in your shell history and in process listings.

​
Which server gets the credential

auth login records the server it authenticated against, so a credential minted for one server is never replayed against another. Resolution order:
  1. --server
  2. RAFFLESIA_API_BASE_URL
  3. the server recorded by auth login
  4. http://127.0.0.1:8081 — a local development engine
Step 4 is the reason a “why is my data empty?” session usually ends with a forgotten --server. If you are talking to the hosted API, set RAFFLESIA_API_BASE_URL=https://api.rafflesia.ai once in your shell profile.

​
Organization scope

Sessions are scoped to an organization. A credential without an organization can authenticate but will be refused on organization-scoped resources — that is a scope problem, not a bad key. rafflesia auth status shows the active credential and the scope it carries.