Skip to main content
Files must be ingested before any of these work. They are not aliases — see Search methods and Choose the right tool. One question, one answer. The service answers with a one-pass fact search or an agent that reads documents, queries tables, and selects documents from the metadata catalog, and returns that route’s result (with a catalog table when the agent answered from the catalog), plus which route it took. Single-shot: no session and no clarification question back. Pass mode fact or agent to run that route directly, with no routing step.
See Automatic search, Python, and TypeScript.

QA

A conversation instead of a single query. Each turn runs the automatic search agent on its own; pass a result’s answer.session_id to ask a follow-up, and the agent may ask back on a genuinely ambiguous question. Chain follow-ups with that conversation’s session; do not share a session across unrelated questions.
See QA, Python, and TypeScript.

Ground quote locations

Search does not wait for bounding boxes. After a succeeded answer, poll every id in its grounding_job_ids: on output for an automatic search answered by the fact route, on output.answer when the agent answered, on answer for a QA turn, and on the result itself for journal-entry testing. Do not POST /v1/ground for those evidences.
An empty list means nothing was planned (postprocessing="none" or no groundable evidence). A missing field is a job from before this field existed — only then call Ground.

Catalog tables

When automatic search’s agent, or a QA turn, answers a filter, rank, or count question from the metadata catalog, the result carries a catalog table: typed columns, one row per matching catalog entry, and exact totals. Search returns matching catalog entries with identities established from the source data. Native register entries stay separate; supporting sections keep their own values and citations in components. total_matches counts entries and total_files counts their distinct source files. Both totals describe all confirmed matches before top-N and paging. Each row has a query-independent entry_id in the current catalog and a source_file_id for its supporting uploaded file. See the API reference for identity behavior on rebuild. You can also ask for fields to show beside each match. These columns carry requested=true. Missing output values remain unexamined without removing the entry; conditions that filter on those values must still be satisfied. A table carries up to 200 rows. When there are more, next_cursor pages the rest: client.search.filtered_page in Python, or POST /v1/workspaces/{id}/filtered-search with { "type": "page", "cursor": "..." }. A page is a new job and re-runs the table’s query against the current catalog.
Read exhaustive before treating a table as a census. catalog_drifted on a later page means the catalog changed since the first page.

Journal-entry testing

Not retrieval. The run writes its own SQL over the ingested ledger tables and publishes every statement as a receipt, so each figure traces to the query behind it. Reach for it when the deliverable is a tested criterion rather than a cited passage.
effort on je-testing is the one knob (low / medium / high); omit it to take the deployment’s own floor. figures is the checkable half of the answer; sql_receipts is its working. exhausted means the step budget ran out before the procedure finished — a partial answer, not a failure. Full field reference: Python, TypeScript. These keep working, as do their endpoints, until they are retired. New code should not start on them. See Fact and deep search and Filtered search for their reference.

Coverage

Every search response can include coverage.restricted_candidates and labels_required when your key cannot see every matching file. See Access labels.