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 Dashboard to work with the active Team, or Read Get Started for the reviewed App request flow.

Passport SSO

Realsee Passport gates the dashboard. When you visit /dashboard, 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

Developer app credentials are issued after an App request has been submitted, reviewed, and provisioned. A provisioned app can expose:

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 used for signed OpenAPI token exchange or server-mediated calls.

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.

Request and review model

The portal does not create credentials immediately. The workflow is:

Step	Owner	Result
Submit App request	Developer	Request is recorded for the active Team.
Review	Realsee	Team, contact email, app name, and use case are checked.
Provision credentials	Realsee	Developer app appears in the dashboard.
Integrate	Developer	Server and SDK code use the provisioned credentials.

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.
Signed OpenAPI requests.

If a browser app needs OpenAPI data, route the call through your own backend. Your server holds the secret, signs the request, and returns only the data your UI needs.

Integration shapes

Browser-only Five SDK preview

Use public open-work data and the Five SDK to render a demo scene while credentials are under review.

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 — submit an App request 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.