Authentication | Realsee Developer Platform

Realsee Developer authentication has two separate layers. Passport authenticates the developer who uses the portal. Developer app credentials authenticate the integration that calls Realsee services.

Open Apps to work with the active Team, or Read Get Started to create a trial app and start integration.

Passport SSO

Realsee Passport gates the dashboard. When you visit /dashboard/apps, Passport authenticates you and returns the Teams you can access. The portal stores an httpOnly session cookie and uses the active Team to scope App requests and Developer apps.

The portal's default Passport SSO source is SSO_DEVELOPER_APP.

Passport identifies the developer. It does not authenticate your application's end users.

See Passport SSO for the sign-in flow and cookie behavior.

Compatibility routes

The portal keeps the following entry-point aliases. Each redirect preserves the original query string, including a safe return destination when one is provided.

Compatibility route	Canonical route
`/login`	`/auth/sign-in`
`/logout`	`/auth/sign-out`
`/signup` or `/register`	`/auth/sign-up`
`/login/callback`	`/auth/sign-in-callback`
`/logout/callback`	`/auth/sign-out-callback`
`/signup/callback`	`/auth/sign-up-callback`

Developer app credentials

A successful Developer app creation immediately completes its App request and saves the AK binding. The app provides:

App key (AK) — the stable credential shown in the dashboard and used by browser-safe SDK flows where supported.
XID — the integration identifier shown with the Developer app's details.
App secret — the server-side secret supplied to the gateway token exchange.

Treat the app secret like a database password. Keep it on your server, never place it in browser bundles, and avoid logging it.

App secret handling

The dashboard never writes an app secret to localStorage or sessionStorage, logs, analytics, URLs, feedback messages, or WeCom. Reveal requires ownership, reCAPTCHA Enterprise, rate limiting, and an audit record. A successful reveal is visible for 30 seconds only and automatically hides on timeout, route or active-Team change, hidden tab, or window blur.

The SaaS default credential identified by category=commerce + xid=realsee_vr is not a Developer app. The portal requests category=open, filters the default credential from normalized results, and never displays or reveals it.

Exchange AK/SK for a gateway token

Run the exchange on your backend using the owning app's AK and SK:

curl --request POST 'https://app-gateway.realsee.ai/auth/access_token' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode "app_key=$REALSEE_APP_KEY" \
  --data-urlencode "app_secret=$REALSEE_APP_SECRET"

The successful response includes data.access_token and data.expire_at, a Unix timestamp in seconds. Inspect the HTTP and business result before using the token. Cache it server-side until shortly before the returned expiry, then run the same credential exchange again. Do not assume a fixed lifetime or a separate refresh-token/rotation API.

Send the token's raw value as Authorization: YOUR_ACCESS_TOKEN for documented /open requests, without a Bearer prefix. This header authenticates the app; your backend must still authorize its own users and the resources it returns. The OpenAPI endpoint guide provides the read-only Team resource-list call, which can succeed with an empty list when there are no suitable VRs.

Create, then integrate

Each Team can have up to three Developer apps. An owner creates a trial app through a saved App request:

Step	Owner	Result
Create trial app	Team owner	App request is saved for the active Team and creation starts.
Complete creation	Portal and upstream app service	App request becomes Completed and is bound to its AK.
Integrate	Developer	Use server-side credentials for `/open` calls, then render scene data.
Join Discord	Developer	Ask questions or discuss continued use of your existing app.

The default 14-day trial is configured by the existing business process. Trial information can initially be pending; it does not postpone request completion. Expiry and disabled status do not free an app place or reverse Completed. The portal does not ask users to activate separate product capabilities.

Use Team and App Management for the dashboard workflow.

Browser and server boundary

Safe in browser code:

Public app key values where the SDK flow explicitly supports them.
Public open-work demo data.
Passport session cookie held by the browser as httpOnly state.

Server-only:

App secret.
Access tokens minted from app credentials.
Gateway token exchange and authenticated OpenAPI requests.

If a browser app needs OpenAPI data, route the call through your own backend. Your server holds the secret, exchanges credentials for a token, authorizes its users, and returns only the data its UI needs.

Integration shapes

Browser-only Five SDK preview

Use public open-work data and the Five SDK to render a demo scene without an account or Developer app. This sample does not start a trial or verify your real API integration.

Browser -> Five SDK -> Realsee public open-work assets -> Browser

Server-mediated OpenAPI integration

Use provisioned credentials on your backend, then hand browser-safe scene data to the frontend.

Browser -> Your server -> Realsee OpenAPI
   ^                         |
   |                         v
   +------ browser-safe scene data

Next steps

Get Started — create a trial app and render a Five SDK demo.
Team and App Management — understand Team scope and request history.
OpenAPI — call OpenAPI from server-side code with provisioned credentials.