​
Two search modes

​
/v1/public/search

Use this endpoint when you want only ranked search results.
  • Google is the default provider
  • both GET and POST are available — GET takes q as a query parameter, POST takes the same fields as a JSON body
  • results are optimized for speed and lower cost
  • no LLM call is made

​
/v1/public/search/answer

Use this endpoint when you want an attributed answer synthesized from fetched result documents.
  • POST only
  • Google only in v1
  • defaults to the top 3 results
  • returns answer.status = "not_configured" if no LLM is available

​
Answer behavior

Grounded answer mode:
  1. runs the Google SERP query
  2. fetches the top result documents
  3. extracts readable content
  4. asks the configured LLM to answer only from that evidence
  5. returns citations with URLs and short supporting quotes

​
Choosing the right mode

  • Use /search for retrieval pipelines, ranking, or your own downstream synthesis.
  • Use /search/answer when you want the API to perform the first-pass synthesis and attribution for you.

​
Cost and control

  • /search is the cheaper path
  • /search/answer costs more because it fetches source documents and may call an LLM
  • both endpoints still support the shared job fields such as wait, cacheTtlSec, and fresh

​
Provider control, diagnostics and deadlines

Use strictProvider: true to honor the selected engine throughout a search. Google recovery attempts remain on Google, and strict DuckDuckGo disables the direct Bing fallback. Defaults preserve the existing provider routing.
POST this body to /v1/public/search. GET accepts strictProvider=true, includeDiagnostics=true and timeoutMs=10000 query parameters. Flags accept only booleans (GET uses true or false). timeoutMs is a positive integer, up to 600000; GET also accepts a JSON options parameter instead of timeoutMs. An opted-in terminal response contains data.meta.searchDiagnostics, on both success and failure. It includes requestedProvider, effectiveProvider, jobId, and routes with each attempt’s provider, route, status and optional errorKind. Provider error messages and internal service addresses are omitted. effectiveProvider on a failure identifies the last attempted engine, without claiming it returned evidence. Cached results identify the cache route. A failed job remains data.status = "failed" with data.error, even when HTTP status is 200. A confirmed empty search remains successful with results: []; engine outages and invalid/challenge bodies are failures. Search failures are excluded from the stable target negative cache. options.timeoutMs on search and /v1/public/scrape bounds the durable job from its creation, including queue wait, retries, retrieval routes and content fetches. Each child receives the remaining budget. Requesting a longer budget cannot extend the service’s per-call ceiling. A client disconnect stops waiting but does not cancel a durable job; an explicit request budget still expires that job. waitTimeoutMs controls how long the public connection waits for that job. Wikipedia article retrieval sends the existing identifying research User-Agent. When a permitted article fetch returns a challenge, it can recover the verified article and its canonical redirect URL through the official MediaWiki article API. The policy follows Wikimedia’s User-Agent guidance. Robots, login and SSRF denials remain terminal. Empty HTML, wrong article identity or an API error never becomes usable evidence.