OpenAPI

Realsee OpenAPI is a set of REST endpoints that read tour data, interactions, and tags visible to a provisioned Developer app. It is server-to-server: every call carries an access token minted from Developer app credentials, and capability access is reviewed before production use.

This page is the overview. The endpoint reference documents the individual paths, request shapes, and response examples.

What OpenAPI gives you

OpenAPI exists for two kinds of integrations:

• Power Five SDK experiences with up-to-date data. Fetch the latest published work.json for a tour, list its tags and interactions, and hand the payload to Five SDK on the client.
• Pipe captured spaces into your own systems. Sync tour metadata into your CMS, your CRM, or your data warehouse without scraping the dashboard.

The surface is read-only for the public Tour Read capability — you cannot publish or mutate works through it. Mutating endpoints (tag creation, hotspot editing, branding configuration) live behind additional reviewed capabilities.

Base URL

https://app-gateway.realsee.ai

All public API endpoints sit under this host, including Argus.

Authentication

Every request needs a bearer access token. Tokens are minted from the app key and app secret that Realsee provisions for the Developer app.

GET /open/work/show.json
Authorization: YOUR_ACCESS_TOKEN
Accept: application/json

The full token-exchange flow — including refresh and rotation — is documented under Authentication. At a glance: POST /auth/access_token with your app key and signed secret returns a short-lived bearer token that you cache and pass to every other call.

Capability review

Every endpoint belongs to a reviewed capability. Include the capabilities your product needs when you submit an App request. Realsee reviews the Team, app name, contact email, and use case before provisioning credentials and enabling the relevant production access.

Use Team and App Management for the App request, review, and provisioning workflow.

Endpoints at a glance

OpenAPI spans roughly 90 paths across the capabilities above. The endpoint reference walks each one in detail; the three below show the shape of the most common reads.

• GET /open/work/show.json — Tour Read. Returns the browser-safe published-tour data after the app has the approved Tour Read capability. Use this as the source-of-truth payload when bootstrapping a Five SDK page.
• POST /open/v1/work/detail.json — Tour Read. Returns the metadata Five SDK needs to initialize an open-work experience: panorama list, geometry references, default camera pose. Read this once per session and cache it client-side.
• GET /open/work/tag/list.json — Interaction Read. Returns the approved tag and interaction metadata associated with a tour. Pair with show.json to hydrate annotations onto a Five SDK canvas.

The reference page documents request parameters, response shapes, and example payloads for each. The list also includes a much larger set of gateway endpoints under Tour Read, Interaction Read, Branding Read, and Asset Read — they are organized in the API browser on the developer portal.

Errors

Every endpoint returns a JSON envelope. Success looks like this:

{
  "code": 0,
  "msg": "ok",
  "data": { /* endpoint-specific payload */ }
}

A non-zero code signals a failure. The envelope is consistent across endpoints — code is the machine-readable error key, msg is a human-readable description, and data is null or absent. Common codes:

HTTP status codes mirror the envelope code where possible (a 403 envelope is returned with HTTP 403), but always inspect the envelope — the gateway sometimes returns HTTP 200 with a non-zero code for tenant-scoped failures.

Next steps

• Endpoint reference — endpoint request and response shapes.
• Authentication — the token exchange details.
• Team and App Management — how App requests become provisioned credentials.