Skip to main content
Reactor uses API keys to authenticate requests. JavaScript apps exchange the key for a short-lived token; Python apps pass the key directly and the SDK does the exchange for them.

Get your API key

1

Create an account

Sign up at reactor.inc.
2

Create an API key

Open the Dashboard, click your user icon, then navigate to API Keys to create a new key.
3

Copy your key

Your key starts with rk_. Store it securely and never commit it to source control.

JavaScript

How it works

Your server exchanges the API key for a short-lived token, which the browser uses to connect. Always mint session-scoped tokens: pass authorization_details naming the models the token may start sessions for. A scoped token can only create and operate its own sessions — it cannot touch other sessions, other models, or any account API. If it leaks, the blast radius is a handful of sessions on the models you listed, for at most the token’s lifetime (1 hour by default).
Server exchanges API key for a token, passes token to browser, browser connects to Reactor

Generate a session-scoped token

Exchange your API key for a short-lived token by making a POST request to the /tokens endpoint with your API key in the Reactor-API-Key header. Always scope the token with authorization_details, naming the models it may start sessions for:
Session-scoped (1-hour expiry)
Custom expiry
The authorization_details entry has three parts:
  • type: "session" (required) — the only supported type today. The token can create sessions and do everything those sessions need (transport negotiation, uploads, clips, session logs), and nothing else.
  • resources.models.match (required) — a non-empty list of models the token may start sessions for. Every listed model must be visible to your API key. There is no wildcard; list each model explicitly.
  • constraints.max_sessions (optional) — how many sessions the token may create in total, from 1 to 500. Defaults to 5. This counts sessions ever created by the token, not concurrent ones: closing a session does not restore capacity.
Session-scoped tokens live for 1 hour by default. Pass expires_after (in seconds) to shorten or extend the lifetime, up to the server ceiling of 6 hours; values at or above the ceiling are silently clamped. The server still returns 200, so always check expires_at (a Unix epoch timestamp) on the response to confirm the actual expiry.
Omitting authorization_details mints an unscoped token that can call every API your key’s roles allow — sessions on any model, account data, key management. Never hand an unscoped token to a browser. Reserve unscoped tokens for trusted server-to-server calls (for example the Platform API), and don’t store your API key in client-side code either: use your server as a proxy to mint scoped tokens, as shown below.

Server-side proxy

Set up an API route on your server that mints a session-scoped token and returns it to your frontend:
Then fetch the token from your frontend and pass it to the SDK:
app/page.tsx

Tokens for a queue or admission-control server

If you run an admission-control layer in front of a fixed pool of sessions — a waiting room gating limited GPU capacity, for example — mint a separate token per admitted slot instead of one shared token for the whole pool. Scope each token to max_sessions: 1 so it can create exactly the one session it is being admitted into:
Size slotLifetimeSeconds to the slot’s whole lifetime: the time an admitted user might take to connect, plus the full session duration. Omitting it defaults to 1 hour, and 6 hours is the ceiling; a session-scoped token can’t be topped up mid-session, so undersizing this strands the session it created. Hand the resulting jwt to the admitted client the same way as the server-side proxy above; its connect() call creates the session and binds it to this token’s grant.
If your API key is compromised, rotate it immediately from the Dashboard. Rotating does not affect active sessions. Need help? Email us at support@reactor.inc.
Adopting an existing session. If your backend creates a session and hands the sessionId to a client, that client must connect with a token that can access the session. Session-scoped tokens are bound to the sessions they create, so the simplest approach is to hand the client the same scoped JWT your backend created the session with. See Sessions.