Node Types and Hierarchy

Every resource in the RealityConnect API is addressed through a content hierarchy of typed nodes. This page catalogs the 10 node types, the parent/child rules that keep that tree valid, and which types you can create directly versus which only appear as the output of another action.

Node types

DataNodeType has 10 values. Only Division, Site, and Folder are created directly through a node-creation endpoint; every other type is produced as a side effect of a domain-specific action: an upload, a bundle creation, processing, or a platform/admin operation.

Type	What it is	Created by
`Organization`	The root of the tree. Every other node is its descendant. `parentId` is `null`.	Provisioned when the organization is created; never through the API
`Division`	A top-level grouping under the organization (e.g. a business unit or region).	`POST /v1/nodes/{parentId}/division`
`Site`	A physical location under a division. Holds data bundles and is the unit addressed by the twin and search routes.	`POST /v1/nodes/{parentId}/site`
`Folder`	A nestable grouping for organizing content under a site or another folder.	`POST /v1/nodes/{parentId}/folder`
`Project`	A RealityPlan design project.	`POST /v1/bundles/{bundleId}/create-project`, once a data bundle has a processed, viewable component
`Twin`	The 3D space descriptor exposed for a site. A twin is addressed by its site’s node id, so there is no separate creation step.	Platform action (publishing a twin)
`DataBundle`	A captured dataset (point cloud, mesh, panoramas, etc.) and its processing outputs.	`POST /v1/nodes/{parentId}/bundle`, given a resolved `dbuPath`
`SiteFile`	A raw uploaded file not part of a data bundle.	`POST /v1/site-files` (a dedicated upload flow, not a node-creation endpoint)
`Artifact`	An attachment or output artifact associated with twin content.	Platform/processing action
`AssetLibrary`	An organization-level library of reusable models.	Provisioned at the organization level; never through the API

Parent/child rules and depth

The three creatable types form a fixed backbone, each accepting exactly one parent type:

Parent	Accepts child type	Route
`Organization`	`Division`	`POST /v1/nodes/{parentId}/division`
`Division`	`Site`	`POST /v1/nodes/{parentId}/site`
`Site` or `Folder`	`Folder`	`POST /v1/nodes/{parentId}/folder`

Folder is the only type that nests under its own type, so it’s the one place depth can grow arbitrarily deep from a single API call. The platform enforces a maximum hierarchy depth beyond this backbone; it does not publish an exact number, but the two error codes below exist specifically to catch a request that would exceed it or misplace a node:

MaxDepthExceeded (returned by PATCH /v1/nodes/{nodeId}/move/{newParentId}): the destination would push the node deeper than the platform allows. Move the node to a shallower position instead of nesting folders indefinitely.
DoesNotMeetHierarchyConstraints (also returned by the move endpoint): the destination parent doesn’t accept this node’s type. Check the table above (or the type’s actual position, via browsing) before moving it.

Creating a node under the wrong parent type is rejected the same way: POST /v1/nodes/{parentId}/site with a non-Division parentId returns 409 { "error": "ParentTypeNotValid" }.

See Error Codes for the full response shape and every other move/delete code.

DataBundle nodes are created under a site or folder, and SiteFile nodes are created under a parent id passed to the upload flow. Both accept the same two parent types as Folder in practice, but through their own domain-specific endpoints rather than a generic node-creation route. The remaining types (Twin, Artifact, AssetLibrary) are positioned by whatever platform or processing action produces them, so browse the tree to find them rather than assuming a fixed slot.

The DataNode shape

GET /v1/nodes/{id}/browse and GET /v1/nodes/search both return nodes in this shape:

{
  "id": "a6f75b3c-f261-4b27-9a2a-9a6cc1234c53",
  "createdAt": "2026-06-01T10:00:00.000Z",
  "updatedAt": "2026-06-01T10:00:00.000Z",
  "name": "Building A",
  "type": "Site",
  "createdById": "8f0b9a2c-8f1b-4a10-9e1c-0b3a2d9a4b7d",
  "parentId": "d2a1c4b7-3e10-4f2c-9a6b-7c1d8e2f3a45",
  "childrenCount": 4,
  "bytesStored": 15728640,
  "thumbnailSignedUrl": null
}

Field	Notes
`type`	One of the 10 `DataNodeType` values above
`parentId`	`null` only for the `Organization` root
`childrenCount`	Direct children only, not the full subtree
`bytesStored`	Subtree storage size in bytes
`thumbnailSignedUrl`	Optional. Only present when the request opts in with `includeThumbnail=true`, and only when a thumbnail exists

Browsing vs searching

Both routes return the same DataNode shape, but they answer different questions and have different limits:

	`GET /v1/nodes/{id}/browse`	`GET /v1/nodes/search`
Answers	”What are this node’s direct children?"	"Find nodes matching these filters, anywhere I have access”
Scope	One node’s direct children	The whole organization tree tied to the access token
`limit`	1–20	1–50
Default `limit`	20	50
Filtering	None, pagination and sort only	Name, type, parent/ancestor, creator, timestamps, storage size, children count

For the mechanics of resolving your first node id and calling browse, see Finding Your IDs. For the full set of search query parameters, filter combinations, and examples, see Searching Business Objects and Nodes.

Twin, DataBundle, and AssetLibrary nodes show up in browse and search results like any other node, but once you have their id you address their content through a different route family rather than /v1/nodes:

Node type	Addressed by id at
`Twin`	`/v1/twin/{contextId}/...` (space descriptor, business object search)
`DataBundle`	`/v1/bundles/{bundleId}/...` (components, processings, processing options)
`AssetLibrary`	`/v1/asset-library/...` (as an `ownerContextId`)

What’s next?

Error Codes for every move/delete/create error code and how to handle it.
Searching Business Objects and Nodes for the full search query surface.