Exa Search and Contents Retrieval Workflow

Overview

Operate Search and Contents as an explicit two-stage retrieval workflow with bounded context, freshness, and cost. Treat credentials, queries, retrieved content, generated output, spend, and destructive state as separately governed boundaries.

Prerequisites

• The target repository, environment, Exa team, product surface, and accountable owner.
• The workload's data classification, latency and freshness promise, cost ceiling, and retention policy.
• Current first-party documentation plus credentials only for a narrowly approved live check.

Current Contract

POST /search can return ranked results and nested contents. POST /contents retrieves known URLs or document IDs and always requires inspection of per-URL statuses. Highlights are token-efficient; text supports deeper analysis; summary is generated. Omitting maxAgeHours uses cache with livecrawl fallback, zero forces livecrawl, and minus one is cache-only.

Authentication

For normal REST work, inject EXA_API_KEY from an approved server-side secret manager and send it only as Authorization: Bearer to the configured first-party Exa API host. Team Management service keys, hosted MCP OAuth or enterprise managed authorization, and payment-protocol calls are separate trust models. Never print, commit, place in a URL, or expose a credential to an untrusted client.