Query a listing's row IDs
Get the record IDs a listing selects, in order, carrying NO cell data.
Takes the same sorts, where and row_status vocabulary as the rows query and answers only the membership-and-order half of it. Pages are correspondingly large — the default is 10,000 IDs — because a page of IDs is a fraction of the size of a page of rows.
Pair it with the rows query’s record_ids mode: fetch an ordering once, then hydrate contents a window at a time. A client holding both can re-sort or re-filter by refetching only the ordering, and reuse every cell it already has.
A POST for the same reason the rows query is one: a filter list has no honest query-string encoding.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Body
Request body for the row-ID manifest.
The same listing vocabulary as the rows query, minus the projection: this asks which rows a listing selects and in what order, not what is in them. Answering it reads no cell payload, so a client can hold a whole table's ordering cheaply and then hydrate only the window it is showing.
Opaque cursor from a previous page's next_cursor.
1024Maximum record IDs per page. Far higher than the rows query's limit because a page of IDs carries no cells.
1 <= x <= 10000Start the listing this many rows in. Mutually exclusive with cursor.
x >= 0Restrict to rows whose cells are errored or fully_computed.
errored, fully_computed Order by these columns, in priority order, instead of display order.
3The predicate tree every returned row must satisfy.