Getting Started
Before you call the RealityConnect API, confirm your environment can reach it, understand how access is enforced, and pick the OAuth flow that matches your integration. Each flow has its own step-by-step guide.
Prerequisites
Section titled “Prerequisites”You’ll need organization admin access to create your first OAuth application. If you don’t have it yet, your org admin can either grant you access or create the application for you.
API URLs and network access
Section titled “API URLs and network access”Before you create OAuth credentials, confirm that the machine or server running your integration can reach the Prevu3D API over HTTPS. Corporate firewalls, proxies, and allowlists often block outbound traffic and cause connection timeouts or DNS errors.
Your integration must be able to reach:
- OAuth and API discovery: https://cloud-api.prevu3d.com
- Regional RealityConnect API (your organization uses one region; your flow guide explains how to discover the exact URL):
Ask your IT team to allow outbound HTTPS access to these hosts if you cannot connect.
Security model
Section titled “Security model”API access is enforced through three layers. A request must pass all of them to succeed; if any layer denies access, the request fails.
Layer 1 — OAuth scopes. Configured on the OAuth application. Scopes define which families of operations the application is allowed to perform (e.g. read:basic, read:hierarchy).
Layer 2 — Content access. Configured on the account that calls the API. For Client Credentials, that is the service user created with your OAuth application. For the Native app flow, it is the signed-in user. This layer determines which nodes (organizations, divisions, sites, etc.) the caller can see and act on.
Layer 3 — Role / permission access. Configured on that same account, per node. Determines what the caller can do with that content (read, edit, manage, etc.).
Each flow guide walks through where and how to configure these layers for your use case.
Choose an OAuth flow
Section titled “Choose an OAuth flow”Pick the OAuth flow that matches how your integration runs, then follow its dedicated guide:
| Flow | Best for | Guide |
|---|---|---|
| Client Credentials | Server-to-server integrations, scripts, and back-end services that act on behalf of your organization | Client Credentials Flow |
| Native app | Integrations where a user signs in through a browser (desktop apps, CLI tools, plugins). Uses Authorization Code + Native Application with PKCE, a localhost redirect, and no client secret. | Native Application Flow |
| Authorization Code + custom HTTPS redirect | Web applications with a callback URL on your own domain | Coming soon |
Not sure where to start? Client Credentials is the simplest path for testing the API or building server-side automation. Use the Native app flow when API calls must run as a specific signed-in user.
Experimental endpoints
Section titled “Experimental endpoints”Some operations in the API reference are marked experimental. In the OpenAPI document they declare x-scalar-stability: experimental.
Treat experimental endpoints differently from stable ones:
- Expect change. Paths, parameters, payloads, responses, errors, or availability may change without the same stability guarantees as the rest of the API.
- Isolate usage. For production workloads, prefer stable operations. If you rely on something experimental, keep it behind a small adapter so you can adjust quickly when the contract evolves.
- Stay current. Follow release notes and revisit the API reference after upgrades so you are not surprised by behavioral changes.
What’s next?
Section titled “What’s next?”Pick a flow from the following options and follow its guide end to end.
Explore the API reference to see all available operations.