page.corvus.getBlock
Return materialized snapshots for the requested `blockIds` plus the cursor at snapshot time. No transitive walk — only the explicit set is returned.
Details · query
| Kind | query |
|---|---|
| Authority | corvus.page |
| Indexed |
Query
query · GETParameters
query stringThe block ids to materialize. Missing blocks are silently omitted from the output.
includeDids
arrayOptional allowlist of editor DIDs whose ops the materialization should consider. When omitted, all editors are included.
Output
application/jsonMaterialized snapshots for the requested `blockIds`. Order is not guaranteed to match the input order; blocks the server doesn't have are omitted (no entry, no error). Tree relationships are encoded on the blocks (sequence/register values reference other block-ids); the caller follows those refs with subsequent `getBlock` calls.
The server-assigned sequence number to resume from.
Similar lexicons
semantic matchLexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.
-
page.corvus.getOps
queryPaginated forward read of an op log scoped to an explicit block set. Pull-based alternative to opening a `page.corvus.subscribeOps` WebSocket at `cursor: 0` — same op shape, same cursor semantics, just delivered as a query page instead of a live tail. Each entry is a `page.corvus.subscribeOps#op` so live and historical paths feed the same applier. Like `subscribeOps`, this query does NOT walk graph relations. Callers fetch ops for the blocks they care about and follow refs explicitly with subse