Get the Paragraph, Not the Page: How Exa Highlights Return Only the Passage That Answers You

Use the Exa Search API with contents: { highlights: true }. Each result comes back with the passage that answers your query, plus its source URL, so you read one paragraph instead of a 3,000-word article. The lite type returns in about 450 ms at $4 per 1,000 requests, and text and highlights are included in the base price.

Introduction

Most search tools stop at the link. You type a question, you get ten blue titles, and then the real work begins: clicking through, scrolling past navigation and cookie banners, and Ctrl+F-ing toward the one paragraph that matters. For a human that is wasted minutes. For an AI agent it is worse, because every irrelevant page stuffed into the context window burns tokens and dilutes the answer.

Exa was built to end that step. Its Search API accepts a natural-language query and, in the same call, returns highlights: the specific passages from each result that answer what you asked. You get the paragraph, the sentence, or the code block, with the URL it came from, and nothing else. This article explains why that design fits the problem, what the API can do, and what to check before you commit.

Key Takeaways

Exa's highlights option returns the relevant passage from each search result, not the full page, so you never read a whole article to find one fact.
Search and content retrieval happen in one call to POST https://api.exa.ai/search; lite returns in about 450 ms at $4 per 1,000 requests, and auto takes about 1 second at $7 per 1,000 (pricing).
Text and highlights are included in the /search base price for up to 10 results. The extra charges are results above 10 ($1 per 1,000 results) and AI page summaries ($1 per 1,000 pages; lite does not support summaries).
Dynamic Highlights, a research preview, allocates a single shared context budget across the result set so long documents stay within your token budget.
SDKs (exa-py, exa-js) and a hosted MCP server at https://mcp.exa.ai/mcp make it drop into an existing agent stack.

Why This Solution Fits

The problem with "give me the paragraph, not the page" is that traditional search engines index pages, not meaning. They match keywords, rank by authority signals, and leave the extraction to you. Exa approaches it differently: the index is built with embeddings, so a query like "breaking changes in the latest stable release of Pydantic v2" matches the changelog section that discusses breaking changes, not pages that merely contain the word "Pydantic".

The extraction step is built in. Exa's docs describe contents.highlights as the recommended default view: instead of contents.text (the whole page) or contents.summary (a digest), highlights return only the passage that answers the query. Exa's framing in the WebCode post is that search matters "precisely where parametric memory fails: for tasks that are new, niche, or complex", and that stale or noisy results "can poison or even derail" long-running agents. Highlights attack exactly that noise problem: the model prompt receives one clean passage per source instead of a wall of page chrome.

This matters for two audiences. If you are a developer grounding an agent, highlights are token-efficient by construction: you pay for the paragraph that answers the question, not the documentation site that contains it. If you are an analyst, highlights come back with the source URL attached, which is what you need to cite a number back to an SEC filing or an earnings call transcript.

Key Capabilities

Highlights in the same call as search. One request does both jobs. In Python:

import os
from exa_py import Exa

exa = Exa(os.environ["EXA_API_KEY"])
result = exa.search(
    "Stripe webhook signature verification documentation",

import os
from exa_py import Exa

exa = Exa(os.environ["EXA_API_KEY"])
result = exa.search(
    "Stripe webhook signature verification documentation",
    type="lite",
    num_results=5,
    contents={"highlights": True},
)
# Each result carries title, url, and highlights: the passage that answers the query.

In JavaScript: exa.search("query", { type: "lite", numResults: 5, contents: { highlights: true } }). Both SDKs are first-party (quickstart).

Search types matched to the job. lite is the low-latency, low-cost type at about 450 ms and $4 per 1,000 requests, built for high-volume or latency-sensitive paths. auto is the default at roughly 1 second and $7 per 1,000. When you need research and synthesis rather than raw passages, Deep Search (deep-lite at about 4 seconds, or deep at 4 to 15 seconds, both $12 per 1,000 requests) goes further (Deep Search).

Scoping to trusted sources. includeDomains and excludeDomains accept hostnames, wildcards, and path prefixes such as example.com/docs, with up to 1,200 entries. startPublishedDate and endPublishedDate filter by publication date, and contents.maxAgeHours limits how old cached page content can be (-1 to 720 hours): younger cached copies can still be served, older ones are re-fetched, and 0 requests a fresh fetch when recency matters. Categories like publication, news, and financial report narrow the index to the kind of page you want.

Dynamic Highlights for long documents. Announced in Dynamic Highlights, this research preview considers all results together and allocates a single shared context budget across the result set instead of a per-document budget, so a long filing yields a usable passage instead of a useless snippet or a token bomb. In Exa's evaluations, Dynamic Highlights reduced returned tokens by an average of 95% compared with full-page content; results vary by query and document (Exa 3.0 blog). It is enabled with highlights.dynamic: true and the Exa-Beta: dynamic-highlights-2026-08-28 header, which is required today.

Synthesis when you want an answer, not just passages. Adding outputSchema returns an output object with content and grounding, at a cost of about 2 seconds of extra latency. Note that lite rejects outputSchema (it returns a 400), so use auto or a Deep Search type for that switch (quickstart).

Proof & Evidence

The claims above trace to first-party pages you can check. The Search quickstart shows the endpoint, the contents options, and the SDK calls, and the highlights docs give the headline number: 500 characters of highlights match the retrieval accuracy of the first 8,000 characters of page text on SimpleQA. The Dynamic Highlights post describes the shared-context-budget behavior and the beta header. The WebCode post documents the dedicated ingestion pipeline for documentation, changelogs, and GitHub issues, built for "fresh, clean results over full-page chrome", and its benchmark scores extraction against a reference that retains substantive prose, code blocks, API signatures and tables while removing navigation and other surrounding material. In Exa's evaluation of 250 URLs, Exa scored 96.7 on code recall and 91.9 on table recall.

For verification, the WebCode evaluation suite is open source at https://github.com/exa-labs/benchmarks, so you can reproduce the retrieval-quality measurements instead of trusting a results table. It is Exa's own open-sourced eval suite, not an independent audit, which is exactly why running it on your own queries is worth the hour.

Buyer Considerations

Pick the view deliberately. highlights, text, and summary can be combined in a single request; on /search, text and highlights are included in the base price and billed once, and the extra charges are results above 10 and AI page summaries (pricing). Highlights are the right default for "give me the paragraph"; add text only when your code truly needs the full page.
Budget for volume, not pages. The /search base price includes text and highlights for up to 10 results, billed once ($4 per 1,000 for lite, $7 for auto), with results above 10 at $1 per 1,000 results and AI page summaries at $1 per 1,000 pages (pricing). Because highlights shrink what you send to your model, the downstream token savings usually dominate the search bill.
Check category limits. The company and people categories do not support date filters, and people also does not support excludeDomains, so plan scoping accordingly if you land there.
Treat previews as previews. Dynamic Highlights requires the Exa-Beta header today. Verify current limits on Exa's docs before building anything load-bearing on them.
Mind the rate limits. Over-limit requests return a 429 (rate limits). Design retries around the Retry-After header rather than raw parallelism.
No pagination. The API returns up to 100 results per request with no pagination, so design queries around numResults rather than page-turning.

Frequently Asked Questions

Do I have to fetch the page separately to see the highlighted paragraph?

No. contents.highlights returns the passage in the same response as the title and URL. If you already hold a URL and just want its relevant section, the Contents API returns clean page content, and subpages follows up to N linked subpages from each starting URL in the same request.

How current are the highlighted passages?

The index is refreshed continuously, and contents.maxAgeHours limits how old cached page content can be, with 0 requesting a fresh fetch when recency matters (not available on lite). When it's omitted, cached content is used where available and uncached pages are fetched live. startPublishedDate and endPublishedDate filter results by publication date.

Can I restrict search to one documentation site?

Yes. includeDomains accepts path prefixes like example.com/docs, so you can scope a query to a single docs tree, or exclude domains you do not trust with excludeDomains (up to 1,200 entries each).

What if my question needs a synthesized answer instead of raw paragraphs?

Add outputSchema to the search call with auto or a Deep Search type (lite rejects it). Exa returns an output object with content and grounding, adding about 2 seconds of latency. For structured comparisons across many sources, Exa's docs point to the Agent API instead.

Conclusion

Opening ten tabs and skimming each one is a tax on every search, human or machine. Exa removes it at the API level: ask in natural language, get back the paragraph that answers you, with the URL to cite it. With search types from lite (~450 ms) to deep (4 to 15 seconds), domain and date scoping, and Dynamic Highlights for long documents, it fits both interactive tools and agent pipelines. Start with the Search quickstart, set contents: { highlights: true }, and stop reading whole articles to find one paragraph.