What Delete Actually Does, Per Resource

“Delete” means different things depending on what you delete through the RealityConnect API. Some resources go into a recoverable trash; most are removed outright. This page is the resource-by-resource reference for planning cleanup or sync-reconciliation logic.

---

Delete behavior by resource

Resource	Delete	Restore	Purge
Data node (division, site, folder, twin, project, data bundle, asset library, etc.)	Soft (moves to trash)	PATCH /v1/nodes/{nodeId}/restore	Automatic 30 days after deletion, or immediately via DELETE /v1/nodes/{nodeId}/hard
POI	Hard	Not available	Immediate
Zone	Hard	Not available	Immediate
Box asset	Hard	Not available	Immediate
Model asset (RealityPlan)	Hard	Not available	Immediate
Asset library model	Hard (blocked while any asset still references it)	Not available	Immediate once unblocked
Library model tag	Hard	Not available	Immediate
Group	Hard	Not available	Immediate
Group membership	Hard	Not available	Immediate
Invitation (organization or node)	Hard (rescind)	Not available	Immediate
Object attachment	Hard (removes only the stored file)	Not available	Immediate

Only data nodes have a trash. Every other resource in this table is gone as soon as the delete call succeeds, with no server-side recovery path.

Data nodes: soft-delete and trash

DELETE /v1/nodes/{nodeId} soft-deletes a node: it moves into the organization’s trash rather than being removed. A trashed node:

• Is listed by GET /v1/trash (paginated, sortable by deletedAt or name).
• Can be restored with PATCH /v1/nodes/{nodeId}/restore, which can fail with 409 StorageLimitExceeded if restoring it would push the organization over its storage quota.
• Is permanently removed with DELETE /v1/nodes/{nodeId}/hard, or automatically 30 days after it was trashed.

Both restore and hard-delete return 409 NoNodeRemoved if the node isn’t currently in the trash, including a node id that was never deleted, and one that’s already been hard-deleted or auto-purged.

Hard-deleting a node also removes its trashed descendants and any derivative rows touching nodes in that subtree. Nodes outside the subtree that happen to derive from something inside it are left untouched.

What blocks a node delete

DELETE /v1/nodes/{nodeId} can be rejected with 409 Conflict for three reasons:

Code	Meaning	Bypass with ?force=true?
NodeHasDerivatives	The node has derivative outputs (e.g. processed results) that must be removed first. The response’s derivatives[] lists exactly which nodes are blocking it.	No
NodeHasBundleDependants	The node’s data bundle has dependants.	No
NodeNotInDeletableState	The node is currently processing or failed processing (isProcessing / isFailed).	Yes

force=true (a query string, exactly "true" or "false") only bypasses NodeNotInDeletableState. A node with derivatives or bundle dependants must have those resolved first; there is no override. See Error Codes for the full response shape and suggested handling.

Asset library models have their own, simpler version of this same guard: DELETE /v1/asset-library/{ownerContextId}/models/{libraryModelId} returns 409 Conflict while any asset still references the model. Once the last reference is gone, the delete is a hard, unretrievable removal, not a soft-delete like a node.

Soft-deleted nodes and browse/search

A soft-deleted node drops out of GET /v1/nodes/{id}/browse and GET /v1/nodes/search immediately and unconditionally: neither endpoint has a parameter to include trashed nodes. The only way to see a trashed node is GET /v1/trash; restoring it is what makes it browsable and searchable again.

For how the node hierarchy and search themselves work, see Node Types and Hierarchy and Searching Business Objects and Nodes.

What’s next?

• Error Codes for the full set of named error codes, including every code referenced on this page.
• What contextId Accepts for resolving the contextId used to address POIs, zones, assets, and attachments.