Trash Resource

Overview

When items are deleted via the UI or API, they are moved to the Trash instead of being permanently destroyed. The item's definition and metadata are serialized and stored separately, then removed from the live system. Items in the Trash can be restored to their original location, or permanently deleted (purged).

There are three separate Trash stores, one for each content repository:
  • Components (comp) — Components and component folders
  • Content (content) — Dashboards, maps, and content folders
  • Tools (tools) — Templates, views, units, cycles, action packages, connectors, and other tool items
The {repo} path parameter in all endpoints below must be one of: comp, content, or tools.

What Goes to the Trash

Trash applies to component-level and entity-level deletes only. When a component is trashed, all of its streams and their sample data are preserved and will reconnect automatically on restore.

The following operations are always permanent and do not go to the Trash:
  • Deleting individual samples (DELETE SAMPLES, samples deleted during delete profile processing, time-range purges)
  • Removing a stream from a component (ALTER TABLE DROP COLUMN, template reconciliation)

Security

  • List: Users see only items they deleted. Users with the TRASH_ADMIN group capability see all items.
  • Restore: Users can restore items they deleted. TRASH_ADMIN can restore any item. The user must also have write rights on the target folder.
  • Purge/Empty: Users can purge items they deleted. TRASH_ADMIN can purge any item. Empty Trash requires TRASH_ADMIN.

Permanent Delete (Bypass Trash)

To permanently delete an item without moving it to the Trash, add ?permanent=true to the standard DELETE endpoint:

DELETE /api/cr/{repo}/{nodeUid}?permanent=true&org={org_uid}

This is available via the REST API only and is not exposed in the UI menus.

List Trash Items

Returns a paginated list of items in the Trash for the specified repository.
URL Description
GET /api/cr/{repo}/trash?org={org_uid} List trash items

Query Parameters:
Parameter Required Description
org Yes Organization UID
start No Pagination offset (default: 0)
count No Number of items to return (default: 50)

Response:
{
  "trash_item": [
    {
      "uid": "trash-entry-uid",
      "entityUid": "original-entity-uid",
      "entityType": "component",
      "name": "Sensor A",
      "id": "sensor_a",
      "iconUrl": "comp_tan",
      "folderPath": "Components/Sensors",
      "crTable": "crc",
      "deletedDt": 1711324800000,
      "deletedBy": "user-uid",
      "deletedByEmail": "admin@example.com"
    }
  ],
  "success": true
}

Get Trash Item Detail

URL Description
GET /api/cr/{repo}/trash/{trashUid}?org={org_uid} Get a single trash item's metadata

Restore

Restores one or more items from the Trash. Restored items are re-created in their original folder (or the root if the folder no longer exists). For components, stream sample data is automatically reconnected.

Conflict handling:
  • Name conflicts: If an item with the same name already exists in the target folder, the restored item is automatically renamed (e.g., "Sensor A" becomes "Sensor A (1)"). The restore succeeds and the response includes the new name.
  • ID conflicts: If an item with the same ID already exists, the restore fails with a validation error. The trash item is preserved. To resolve, either delete the conflicting item first, or use the newId override in the request body.
  • Folder conflicts: If a folder with the same name already exists at the original path, the existing folder is reused. Saved permissions from the trashed folder are applied to the existing folder.
Folder permissions: When restoring an item that was inside a folder hierarchy, any ancestor folders that are also in the Trash have their permissions automatically restored to the recreated folder path. The ancestor folder trash entries are removed after their permissions are applied.

Single Item Restore

URL Description
POST /api/cr/{repo}/trash/{trashUid}/restore?org={org_uid} Restore a single trash item

Optional Request Body (conflict overrides):
{
  "newName": "Sensor A (restored)",
  "newId": "sensor_a_2",
  "targetFolderUid": "folder-uid"
}

Batch Restore

URL Description
POST /api/cr/{repo}/trash?action=restore&org={org_uid} Restore multiple trash items

Request Body:
{"trashUids": ["uid1", "uid2", "uid3"]}

Purge (Permanently Delete from Trash)

Permanently deletes one or more items from the Trash. This also cleans up any associated sample data and file stream data. This operation cannot be undone.

Single Item Purge

URL Description
DELETE /api/cr/{repo}/trash/{trashUid}?org={org_uid} Permanently delete a single trash item

Batch Purge

URL Description
POST /api/cr/{repo}/trash?action=purge&org={org_uid} Permanently delete multiple trash items

Request Body:
{"trashUids": ["uid1", "uid2", "uid3"]}

Empty Trash

Permanently deletes all items in the Trash for the specified repository. Requires the TRASH_ADMIN group capability.
URL Description
DELETE /api/cr/{repo}/trash?org={org_uid} Empty the entire trash for this repository

Note: Empty Trash does not clean up orphaned sample data for individual items. Use batch purge for that.