List Asset Relationships & Subscribers

List the relationships an asset has — the other assets that reference it ("what is using this?") and the users subscribed to its notifications.

Cascade exposes two related discovery questions through this single endpoint:

1. "What relationships does this asset have?" — i.e. what references it: "which pages use this block?", "which pages link to this file?", "which content-types use this data definition?". The referenced asset is the query target; the assets that point at it show up in the response.

2. "Who gets notified when this asset changes?" — user/group subscribers, both auto (ownership/workflow/group) and manual (opt-in).

Directionality matters: the lookup runs against the asset being referenced, NOT the asset doing the referencing. If a page embeds a block, query the BLOCK to find the page. Querying the page will NOT list its embedded blocks — it will list the assets that reference the page.

Args:

• identifier (object, required): The asset whose relationships/subscribers to list

  • id (string, optional): Asset ID. Prefer id when known; Cascade auto-resolves path→id server-side when only path is given.

  • path (object, optional): { path, siteId OR siteName } — valid fallback when id is unknown.

  • type (string, required): Entity type of the asset. Use the EntityType string (e.g. "page", "block_XHTML_DATADEFINITION", "contenttype") — NOT the camelCase envelope key ("xhtmlDataDefinitionBlock", "contentType"). Most asset kinds differ between the two schemes; see IdentifierSchema.type / cascade://entity-types.

Returns: Cascade OperationResult: { success: true, subscribers: [ { id, type, path: { path, siteId, siteName } }, ... ], manualSubscribers: [ { id, type, path: { path, siteId, siteName } }, ... ] } Entries may be related assets (pages, content-types, ...) that reference this one, users subscribed to notifications, or both — distinguish by type. On failure: { success: false, message: "" }

Examples:

• Use when: "What relationships does this block have?" / "Which pages use this block?" -> { identifier: { type: "block_XHTML_DATADEFINITION", id: "" } } then inspect response entries.

• Use when: "Which assets link to this file?" -> { identifier: { type: "file", id: "" } }.

• Use when: "Who gets notified when /about changes?" -> { identifier: { type: "folder", path: { path: "/about", siteName: "www" } } }.

• Don't use when: You want outbound relationships — i.e. "which blocks does this page embed?". That direction isn't queryable; read the page and inspect its body.

• Don't use when: You want to read messages sent — use cascade_list_messages.

Error Handling:

• "Asset not found" when the identifier doesn't resolve

• "Permission denied" when credentials lack read access. Responses are JSON text; structuredContent is authoritative when the response fits. Oversized responses return bounded _cache metadata for cascade_read_response. For cascade_read, read_mode controls preview versus raw Cascade payload shape.