Finding Your IDs: Organizations, Nodes, and Context

Nearly every RealityConnect API path carries an id (contextId, organizationId, ownerContextIds) that has to come from somewhere before you can call it. This page shows where those ids live in your organization’s node tree, how to discover them starting from nothing but an access token, and which route families expect which one.

---

Everything is a node

Your organization’s content (divisions, sites, folders, twins, data bundles, asset libraries, and more) is one tree of data nodes. Every node has a uuid id and a DataNodeType (Organization, Division, Site, Folder, Twin, AssetLibrary, Project, SiteFile, Artifact, DataBundle). Most path parameters you’ll see across the API, including contextId, organizationId, nodeId, parentId, and ownerContextId, are simply the id of one of these nodes.

Note

This page is about finding node ids and knowing which one a route wants. For the full rules on which node type can contain which, see Node Types and Hierarchy.

Walk the tree from a token

You can go from an access token to any node id in your organization with two calls:

1. Resolve your organization id

GET https://cloud-api.prevu3d.com/oauth/api-info
Authorization: Bearer <access_token>

{
  "organization": {
    "id": "217ebd23-ec54-4af0-a6d6-4a441a6d1966",
    "name": "Test Organization"
  },
  "apiUrl": "https://api-ue1.prevu3d.com/realityconnect-api"
}

organization.id is the root of your node tree: the organizationId most routes want. apiUrl is your regional RealityConnect API base. See Getting Started and the OAuth flow guides for the full token exchange.

2. Browse down from there

GET {apiUrl}/v1/nodes/{id}/browse
Authorization: Bearer <access_token>

Pass the organization id to see your divisions. Each item in the response is itself a node with its own id and type; pass that id to the same route to browse one level deeper (a division’s sites, a site’s folders and twins, and so on). There’s no separate “list my divisions” or “list this site’s twins” endpoint: browse is the one call, repeated down the tree.

Tip

If you already know roughly what you’re looking for by name or type, GET /v1/nodes/search can jump straight to it (filtered by nodeTypes, parentId, or ancestorId) instead of browsing level by level.

Which id does each route family want?

Route family	Id	What it identifies
/v1/twin/{contextId}/... (assets, POIs, zones, drafts, object, search, space)	contextId	A twin, the site it belongs to, or one of its drafts. Resolved directly; a design project or layout id 404s here.
/v1/reality-plan/{contextId}/... (space, model-assets, layouts, bundles)	contextId	A design project (RealityPlan Project), or one of its layouts. Resolved directly; a twin, site, or twin draft id 404s here.
/v1/nodes/{id}/browse	id / nodeId / parentId	The data node itself, at whatever level you’re operating on.
GET /v1/asset-library/-/models (ownerContextIds query param)	ownerContextIds	The id(s) of whichever context owns the library: your organization id or a RealityPlan Project id. Not the id of an AssetLibrary node. This route currently expects at least one value; omitting it returns 400.
/v1/asset-library/{ownerContextId}/... (path param, e.g. create/read/update a library model)	ownerContextId	Same as above: the organization or RealityPlan Project that owns the library, not the AssetLibrary node’s own id.

Note

contextId isn’t one universal id type: what it resolves to depends on which route family it appears on, and a syntactically valid id from the wrong family 404s rather than erroring more specifically. See What contextId Accepts for the full resolution rules.

What’s next?

• Explore the API reference for full request/response schemas.
• See Searching Business Objects and Nodes for filtered node and object lookups.
• See OAuth Scopes for what read:hierarchy and write:hierarchy grant.