Exa Retrieval Architecture Boundary

Overview

Design an Exa architecture that separates query policy, retrieval, content handling, asynchronous state, citations, and evidence. 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

Use Search for ranked discovery, Contents for known URLs, Answer for a direct cited response, Agent for multi-step research, Monitors for recurring discovery, Websets for verified and enriched sets, and Batch for enabled enterprise offline volume. Each product has distinct lifecycle and trust boundaries.

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.