API

Authentication

RTIE resolves every authenticated request to a tenant-scoped actor. Use RTIE API keys for server integrations, Supabase JWTs for hosted Console/first-party flows, BYOA/OIDC adapters for third-party runtime users, and short-lived RTIE session tokens for public or agent-driven sessions.

RTIE API keys

API keys are generated in Console and are scoped to a tenant. Send them as a Bearer token or through the X-API-Key header.

curl https://api.rtie.ai/v1/me \
  -H "Authorization: Bearer rtie_live_..."

curl https://api.rtie.ai/v1/me \
  -H "X-API-Key: rtie_live_..."

Hosted auth JWTs

RTIE Cloud and first-party hosted products can use Supabase Auth. RTIE maps the provider user ID to an internal RTIE user ID, then resolves tenant membership from RTIE Postgres tables.

curl https://api.rtie.ai/api/auth/user \
  -H "Authorization: Bearer SUPABASE_JWT"

BYOA and session tokens

Third-party apps do not need to move users into Supabase Auth. Your backend can verify Auth0, Firebase, Cognito, custom OIDC, or guest identity, map it to an RTIE actor, and call POST /v1/runtime/connect to mint a short-lived module/session token.

curl https://api.rtie.ai/v1/runtime/connect \
  -H "X-API-Key: rtie_live_..." \
  -H "Content-Type: application/json" \
  -d '{"modules":["rooms","presence","chat"],"actor":{"type":"end_user","id":"auth0:user_123","identityProvider":"auth0"}}'

Tenant boundaries

• Tenant identity is resolved by middleware before module handlers run.
• Business logic should use the resolved tenant, not a caller-supplied tenant ID.
• Provider user IDs are stored as external IDs. RTIE internal UUIDs remain the primary keys.

Authentication errors