Skip to main content

Getting a key

Create an account at platform.r3al.ai and verify your email, then mint a key on the SDK / API keys page. Live keys use the r3l_live_ prefix.

Two ways to authenticate

Every /v1/* request (except /v1/auth/*) reads an Authorization: Bearer <token> header. The token can be either of:
1

A standalone API key

Minted via POST /v1/keys or the SDK page (prefix r3l_test_ or r3l_live_ depending on env). Meant for the SDK, scripts, CI, or integrations. This is the credential the Python SDK uses.
2

A session token

Minted by POST /v1/auth/login or /register (prefix r3l_sess_, 30-day expiry). This is what the dashboard uses once you’re signed in; it doubles as an API credential.
The key secret is shown once, at mint time. Store it securely; if you lose it, revoke it and mint a new one.

Roles: Admin, Developer, Member

Real platform accounts (POST /v1/auth/register) each have exactly one role, enforced server-side on every mutating endpoint:
Role checks apply when the caller authenticated with a session token (a logged-in account). A standalone API key bypasses role checks: role tiering is an account concept layered on top of the API, so the SDK and scripts using a plain key keep unrestricted access.
The first account on a team becomes Admin automatically. Every self-registration after that defaults to Member; an Admin invites someone as Developer or Admin explicitly (POST /v1/auth/invites with a role field).

Changing a role

Admin-only. Refuses to demote the platform’s last remaining Admin (409 Conflict) so nobody can lock out all role management by accident.