One page of what was deleted from a collection and can still be restored, newest first. Each item is what one delete removed, as a restore brings it back whole: a folder deleted with its contents is one item, and so is a multi-select delete (rootCount items selected, some named in otherRootNames). itemCount says how many records it holds, the folder included.

A folder deleted with DELETE /knowledgeBase/{kbId}/folder/{folderId} takes its contents along. A folder deleted with DELETE /knowledgeBase/record/{recordId} goes to the trash alone (itemCount 1): the records inside it stay live. Restore an item with POST /knowledgeBase/record/{recordId}/restore, using its id.

Needs "Move Deleted Records to the Trash" on in Labs.

Who sees what: the list holds what the caller may restore. OWNER and WRITER see every item; FILEORGANIZER sees single files only; other roles are refused. The workspace and user always come from the sign-in.

Removed for good: the scheduled cleanup may remove an item from removableAfterTimestamp on (at least 14 days after it was deleted by default; it runs every 14 days, so an item stays 14 to 28 days). It is absent when the retention settings can't be read.

An item whose folder is also in the trash (parentInTrash) can only be restored after that folder.

Request: query parameters other than page and limit are ignored. A page past the last one is answered 200 with no items.