List Queries
List your stored queries, newest first, scoped to the environment of the API key you call with (a production key lists production queries).
Page with cursor until next_cursor is null; there is no total count. A page can be shorter than limit while next_cursor is still set when a filter trimmed it. Your key’s environment is part of the index, so pages come back full in either direction; collection and status are applied while reading, so a page can be shorter than limit while next_cursor is still set, and the API keeps reading to fill it. from and to bound the window on the index, so pair them with the other filters on large histories.
include inlines the same bodies GET /v2/queries/{query_id} returns, per row, so a feed and its previews can come from one request: results (retrieved chunks in one normalised shape), request, response. Each costs a stored-body read, so limit is capped at 25 when include is set. The four body fields are always present on every row and null unless requested.
History contains completed, non-streamed queries. Bodies are archived 90 days after the query (body_status: archived); the summary rows are kept.
Headers
Query parameters
Filter by query status (completed or failed). Only completed queries are recorded today.
Only queries created at or after this ISO-8601 date or timestamp (UTC when no offset is given).
Only queries created before this ISO-8601 date or timestamp (exclusive).
Order by creation time: desc (newest first, default) or asc.
Queries per page (1–100; at most 25 when include is set).
Continue from a previous page’s next_cursor.
Comma-separated bodies to inline on each row: results (normalised retrieved chunks), request, response. Each costs a stored-body read; without it a row is a summary.