Search Best Practices

This guide assumes you already have a working Search API request. It covers how to improve that request following Exa’s recommended best practices.

Start with the smallest useful request

The best baseline is a natural-language query with highlights:

result = exa.search(
    "Recent technical articles comparing hybrid and semantic retrieval for RAG systems",
    contents={"highlights": True},
)

const result = await exa.search(
  "Recent technical articles comparing hybrid and semantic retrieval for RAG systems",
  { contents: { highlights: true } }
);

curl -s -X POST "https://api.exa.ai/search" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $EXA_API_KEY" \
  -d '{
    "query": "Recent technical articles comparing hybrid and semantic retrieval for RAG systems",
    "contents": { "highlights": true }
  }'

This gives you ranked pages and token-efficient context per page, relevant to the query. Add additional parameters only as needed:

Parameter	Add it when
`type`	Adjusting to meet a latency budget or depth requirement
`numResults`	Fewer pages for a smaller context window, or more for broader recall
`outputSchema`	Synthesizing results or structuring them into JSON
`maxAgeHours`	Cached page content may be too old
Domain or date filters	Results outside the constraint would be unusable

Search vs. Deep Search

Standard search retrieves and ranks pages for a query. Deep Search runs a research process that can search iteratively, inspect what it found, refine the search, and synthesize a grounded result.

Need	Start with
Ranked pages for a well-formed query	`auto` or `fast`
Difficult searches, synthesis across many results, or structured outputs that cannot be filled with a single search (3+ fields)	`deep`
Long-running research, list building, or multi-hop enrichment	Exa Agent

Deep modes are recommended by default when using outputSchema. Read the Deep Search guide for full instructions and examples.

Improve retrieval quality

When results need improvement, change one part of the request at a time.

Clarify the query

Describe the pages you want, not a bag of keywords. Include the subject and any source type, time period, or other detail that changes what a relevant result looks like.

Benchmark papers evaluating long-context retrieval methods on legal documents

Read the response in layers

Look at the titles, URLs, publication dates, and highlights before changing the request.

{
  "results": [
    {
      "title": "Long-Context Retrieval Methods on Legal Documents",
      "url": "https://arxiv.org/abs/2608.00000",
      "publishedDate": "2026-08-26T00:00:00.000Z",
      "highlights": [
        "We compare long-context retrieval methods across legal document benchmarks..."
      ]
    }
  ]
}

The title and URL show the kind of source Exa retrieved, publishedDate shows its recency, and the highlight shows the evidence that matched the query. Refine the query to retrieve different pages, add date filters to narrow the time period, or fetch full text when you need more context from a useful result.

Add only hard constraints

Use includeDomains, excludeDomains, and publication-date filters only when a result that violates the constraint cannot be used. Put retrieval preferences in the query and, when synthesizing, put response instructions in systemPrompt.

Change the search mode last

Use a faster mode for a latency requirement or a deep mode when the retrieval process itself needs iteration and reasoning. A different mode cannot repair an underspecified query.

Keep a small set of representative queries while tuning. Compare result relevance and downstream task success across the set instead of optimizing for one example. Record requestId, searchTime, and costDollars so regressions are reproducible.

Budget latency and context

Each control spends a different resource:

Control	What it adds
More results	More pages, response data, and downstream context
Full text	Broader page context and a larger payload
`summary`	One additional language model call per result
`outputSchema`	Synthesis across the retrieved results
`contents.maxAgeHours: 0`	A fresh page fetch instead of cached content
Deep search types	Iterative search, synthesis, and reasoning

For a real-time path where cached content is acceptable, combine the lowest-latency mode with highlights and cache-only content:

result = exa.search(
    "Recent product updates from major AI labs",
    type="instant",
    contents={
        "highlights": True,
        "max_age_hours": -1,
    },
)

const result = await exa.search("Recent product updates from major AI labs", {
  type: "instant",
  contents: {
    highlights: true,
    maxAgeHours: -1
  }
});

curl -s -X POST "https://api.exa.ai/search" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $EXA_API_KEY" \
  -d '{
    "query": "Recent product updates from major AI labs",
    "type": "instant",
    "contents": {
      "highlights": true,
      "maxAgeHours": -1
    }
  }'

Do not use this recipe when page freshness is part of correctness. Start from auto and default freshness unless the product has a measured latency target. Allocate context across results with Dynamic Highlights: Use contents.highlights.dynamic when several pages will feed the same agent or RAG context. Exa spends more context on useful results and less on redundant ones.

{
  "query": "What is the current Fed interest rate?",
  "contents": {
    "highlights": {
      "dynamic": true
    }
  }
}

Keep regular highlights when every result needs its own excerpt or a per-page character limit. Requests that set dynamic: true require the Exa-Beta: dynamic-highlights-2026-08-28 header. See Dynamic highlights for response behavior and limitations.

Tips for common use cases

If you need	Use	Avoid
Newer publications	Put the time window in the query or use publication-date filters	`maxAgeHours`
Fresh content from pages that change	`contents.maxAgeHours`	Publication-date filters
A preferred kind of source	Query phrasing; `systemPrompt` when synthesizing	A hard domain allowlist
Results only from approved sources	`includeDomains`	Repeating `site:` in the query
A small structured output	`outputSchema` with standard Search	Choosing Deep only because the output is JSON
A multi-item researched output	`deep` with `outputSchema`, or Exa Agent	Expecting one retrieval pass to gather every item
More context from a few pages	Search with highlights, then call Contents	Full text for every result
Lower latency	Measure `fast` or `instant` with compact content	Adding freshness or synthesis controls by default

When to use another endpoint

Use a different Exa endpoint when the task changes shape:

Task	Use
Long-running research, list building, or enrichment	Exa Agent
The URLs are already known	Contents
Run a search on a schedule	Monitors

Next steps

Search API reference

Every request parameter and response field.

Search quickstart

Core request shapes, filters, output, and freshness.

Contents API

Extract highlights or full text from pages you already know.

Exa Agent

Long-running research, list building, and enrichment.

Get Started

Search

Agent

Other APIs

SDKs

Integrations

Admin

Websets

Search Best Practices

Start with the smallest useful request

Search vs. Deep Search

Improve retrieval quality

Budget latency and context

Tips for common use cases

When to use another endpoint

Next steps

Search API reference

Search quickstart

Contents API

Exa Agent

​Start with the smallest useful request

​Search vs. Deep Search

​Improve retrieval quality

​Budget latency and context

​Tips for common use cases

​When to use another endpoint

​Next steps

Search API reference

Search quickstart

Contents API

Exa Agent

Start with the smallest useful request

Search vs. Deep Search

Improve retrieval quality

Budget latency and context

Tips for common use cases

When to use another endpoint

Next steps