POST /api/public/v1/research/search/ to find relevant evidence in studies whose reports have been indexed.
Content types
Search ranks candidate content IDs. The API validates those IDs against the current database index and hydrates
content from persisted canonical JSON. It never returns generated answer text; generated_content_returned is always false.
Results are grouped by study in the studies array, in the same order as the requested study_ids. Every requested study has one entry, even when it has no matches or has not been indexed. The limit is the maximum number of matches across all study groups.
index_status to check freshness:
Each study group includes
latest_report_id and indexed_report_id when available, so clients can show progress without treating an existing but stale store as current. A not_indexed study has an empty results array; this is distinct from an indexed study with no matches.
limit accepts 1–50. When next_cursor is non-null, pass it back with the same query, filters, and limit. Continue until it is null. The final page can be empty. Study access and current indexed records are checked on every page.Ask across your research
Use the same study and date filters withPOST /api/public/v1/research/answer/ when you need a concise answer rather than raw records:
answer text with numbered references such as [1], citations[] with canonical content_id, study_id, content_type, report_id, and optional interview_id, plus per-study index status. insufficient_evidence is true when the indexed records do not support an answer. Generated sentences are not verbatim interview quotes; inspect the cited record and interview before quoting a participant.
To inspect source evidence, resolve a finding’s reference_ids through GET /api/public/v1/studies/{study_id}/report?view=references, then use the reference’s interview_id with the interview API. Participant-response results include their public interview_id both on the result and in content when it can be resolved. Use that value with GET /api/public/v1/interviews/{interview_id}. Interview messages are paged; follow next_message_offset to retrieve later passages.
