File Search API
Captain File Search retrieves source chunks from indexed files. Use v3 for new applications. It has cleaner response fields, explicit include controls, document inspection, chunk metadata, and graph relations.
v2 remains available for existing clients. It keeps search_results and content so older code does not break.
Query With v3
See the v3 Query endpoint for the full request and response schema.
Tuning reranking
rerank accepts a boolean or an object. true uses the defaults — voyage-rerank-2.5
over a candidate pool of limit × 3. The object form tunes it:
model— pick a reranker. Voyage cross-encoders:voyage-rerank-2.5(default) andvoyage-rerank-3(aliasesrerank-2.5,rerank-3). Gemini LLM rerankers:gemini-2.5-flashandgemini-3.8-flash— a higher quality ceiling on complex queries at higher latency, best with small candidate pools. The family aliasesvoyageandgeminiresolve to each family’s default. Unknown values return a 400 listing the allowed set.candidate_limit— how many fused retrieval candidates are fetched and reranked before the toplimitresults are returned. Defaults tolimit× 3; must be ≥limit, capped at 200. Raising it can lift recall on corpora with many near-duplicate documents, at the cost of rerank latency.enabled— defaults totruein the object form;{"enabled": false}is an explicit opt-out, exactly likererank: false.
The response’s rerank envelope reports what actually ran: used, reason, and
— when reranking was applied — model and candidate_limit. The same parameter
shape is accepted on the v2 Query endpoint.
Response Shape
v3 returns results, and each result uses text for chunk text.
Use Advanced Search & Relations for metadata filters, chunk custom_metadata, region data, relations, and relation-aware queries.
Cap a Document’s Share of Results
limit counts chunks, not documents, so one long file can occupy the whole result page. max_chunks_per_document drops a document’s surplus chunks and backfills the page with the next best chunks from other documents. Ranking is unchanged; only the page composition is.
Return the Top Documents
top_documents: N answers “give me the N most relevant documents”. The response gains a top_documents array ranking documents by their best chunk across the whole ranked pool (which is deeper than the page). This is a document-level view of the ranking, not to be confused with include.document, which only attaches each chunk’s parent-document info to the flat results. The flat results list is unaffected (and stays byte-identical whether top documents are requested or not), and the top-level limit keeps counting chunks.
Each entry’s document_id is the stable identifier: it works with Get Document and survives re-indexing, unlike the per-generation file_id. chunk_count reports how many of the document’s chunks appeared in the ranked pool, and chunks lists every one of its chunks that made results, ranked by score, so each reference resolves by chunk_id. A document can rank on pool evidence alone and carry an empty chunks list; max_chunks_per_document keeps the page diverse enough that every top document surfaces its chunks. Both options compose with reranking, boosts, and relations.
Documents and Chunks
Use document and chunk endpoints when your application needs stable source objects outside the search response:
- Get Document: inspect a document and its chunks.
- List Chunks: page through chunks in a document.
- Get Chunk: fetch one chunk by ID.
These endpoints are useful for citations, review flows, and source-grounded UI state.
v2 Compatibility
Existing v2 clients should continue using v2 Query. v2 keeps the old field names:
Do not document v3 behavior as v2 behavior. v2 does not return v3 fields such as results, text, custom_metadata, relations, or related_chunks.