Browse the knowledge graph from a node
Open a node in the knowledge graph and see what is inside it — a file explorer across every connected source.
Call it with no nodeId for a flat listing of every record group and record the caller can reach, newest first. This is a starting point to pick a node from, not a roster of connected apps — app nodes are never returned in a listing, though an app's id is accepted as a nodeId and lists that app's record groups. Pass a node's id to descend: record groups contain records and folders, and a record contains its own children — comments, attachments, sub-tasks — plus a related section of cross-referenced records, such as the Confluence page linked from a Jira ticket. nodeId is tolerant: a URL or an issue key such as PA-1787 is resolved to its record before navigating, so a link can be pasted straight in without a separate lookup call.
The response carries a rendered text view — breadcrumbs, the current node, the children listing, Related:, and a closing Next: line naming a follow-up call. The structured fields carry the same information for programmatic use.
When to use this vs. the other record endpoints:
- This endpoint is for structural exploration — "what is in this project", "what is attached to this ticket", "what else links to this page". It returns names, types and IDs; it never returns document text.
- GET /connectors/record/{recordId}/content returns one record's actual parsed text. Use it once navigation has identified the record you want to read.
- GET /connectors/record/lookup is the way in when you hold a URL or an issue key rather than a position in the tree.
Typical flow: call with no nodeId to see what is reachable → pass a record group's id to list its records → take a row whose is_record is true and call GET /connectors/record/{recordId}/content to read it.
Paging and depth: results are paginated; pagination.has_next tells you whether to request the next page. depth above 1 returns all descendants down to that level as one flat list, each row carrying its own level, instead of only direct children.
Scope: everything the caller can read, across both connectors and Knowledge Base collections. No connector-level filter is applied — the listing is bounded by per-node permissions alone.
Permission scoping:
rows and related carry only nodes the caller can see, and the opened node itself is access-checked before any of its details are returned. A node that does not exist and a node the caller cannot access are deliberately indistinguishable — both return an empty view rather than an error.
breadcrumbs is the exception: the ancestor trail is resolved by id alone, without a permission check. For a record shared directly with the caller, it can therefore name ancestors the caller cannot open. Treat breadcrumb entries as labels, not as nodes guaranteed to be navigable.
Query parameters
The node to open. Take it from an id in a previous navigate or lookup response. Omit it entirely for the flat listing of everything reachable — the usual starting point. A URL or an issue key such as PA-1787 also works: it is resolved to its record automatically.
Page number, 1-indexed.
Children per page. The minimum is 50 — smaller values are rejected rather than silently raised.
Levels of descendants to return in one call. Above 1, rows is a flat list of all descendants down to that level rather than only direct children, and each row carries its own level.
Restrict children to these node types. Repeat the parameter for multiple types: ?nodeTypes=record&nodeTypes=folder.
Filter children by source creation time. ISO 8601 YYYY-MM-DD, or a full datetime that MUST carry a timezone offset — a naive datetime is rejected rather than assumed to be UTC.
Filter children by source creation time. YYYY-MM-DD is inclusive of the whole day.
Filter children by source modification time.
Filter children by source modification time.
Response
Successful operation. A node that does not exist or is not accessible returns an empty view (null current, empty rows) rather than an error.