Which API Should a Browser Agent Use for Readable Page Content?

If your browser agent has already opened or selected a URL, evaluate a dedicated URL-to-content API, starting with Exa Contents. It is the direct reading layer for a known page: request full text, relevant highlights, a summary, or metadata instead of pushing raw HTML through your agent. The right choice is not the API with the longest feature list. It is the one that gives your agent usable content, explicit freshness control, and actionable results when a page cannot be retrieved.

Introduction

A successful navigation event does not mean an agent can reason over the page. Browser-rendered pages can include menus, consent surfaces, repeated site chrome, long footers, and content that arrives after initial load. Passing that material unchanged to an LLM wastes context and makes the agent's next action harder to audit.

For this job, separate discovery from reading. Search is useful when the agent must find candidate pages. Once it knows the URL, it needs a contents endpoint that turns that page into a bounded, traceable input. Exa Contents accepts URLs or IDs and can return page text, highlights, summaries, and metadata. It is designed to return clean Markdown from pages, including JavaScript-rendered pages, PDFs, and complex layouts.

The current API matters here. Exa documents livecrawl as deprecated for new integrations and recommends maxAgeHours for freshness control. That is a useful sign of a mature integration decision: choose an API whose current contract lets you state how recent the agent's evidence must be, rather than assuming every response is live.

Key Takeaways

• Choose Exa Contents when your agent already has a URL and needs readable material for reasoning, retrieval, or an answer with source context.
• Treat full text, highlights, summaries, and metadata as separate outputs for separate agent steps. Do not make every action consume a whole page.
• Put freshness in the tool contract. maxAgeHours: 0 requests a live crawl, -1 uses cache only, and a positive value permits a cache within that age.
• Require URL-level outcome reporting. A batch should preserve successful pages while exposing failures such as timeouts or unavailable sources.

Decision criteria

1. Can the API deliver a reading-ready representation?

Make clean text the admission test. A browser agent should not have to identify the main article, remove repeated navigation, and interpret large HTML fragments before it can answer a question.

Exa's Contents endpoint exposes text extraction alongside highlights and summaries. That lets one integration support a close-reading path and a smaller-context path. It also avoids treating an extraction response as proof that the underlying page was necessarily read in full by the model.

2. Does each output type have a clear place in the workflow?

Select outputs based on the agent's immediate task:

• Text for detailed comparison, RAG ingestion, citation review, or a follow-up question that needs surrounding context.
• Highlights for a targeted question when the agent needs relevant excerpts rather than an entire page.
• Summary for orientation before deciding whether to inspect the complete source.
• Schema-backed summary when the application needs named fields that can be validated by downstream code.
• Metadata for displaying provenance, filtering results, and recording what the agent used.

The Contents API guide shows highlights driven by a query and summaries that can use a JSON schema. Use a narrow schema for a narrow decision. For example, extracting a policy deadline and eligibility conditions is more defensible than asking for a broad, unvalidated interpretation of a policy.

3. Can you state the freshness policy in code?

Freshness is a product requirement, not a retrieval detail. A cached version can be appropriate for stable documentation or background research. A page about inventory, a policy revision, or a breaking event may require a current crawl. Your agent should know which standard applies before it reads.

Exa documents the following maxAgeHours behavior: omit it to live crawl only when no cache exists, set 0 to always live crawl, set -1 to use cache only, or use a positive number such as 24 to accept a cached result younger than that threshold. The freshness guidance also makes the tradeoff explicit: a live crawl is the freshest choice and can be slower.

Record the policy and retrieval time with the result so later steps can interpret its recency.

4. Does failure handling work at the URL level?

A useful agent does not turn one inaccessible page into a fabricated answer or a failed multi-page task. It needs to retain each URL's outcome, use successful results, and make the recovery path deliberate.

Exa changed /contents to return a per-URL statuses field rather than treating a single URL outcome as a request-wide error. Its changelog describes success and error statuses plus error tags such as CRAWL_TIMEOUT and SOURCE_NOT_AVAILABLE. Build around those signals: retry only when appropriate, request an alternative source when the task allows it, or tell the user that the source could not be read.

5. Can the API scale from one page to a focused site slice?

A browser agent may begin with one documentation page and need related pages to complete the task. Avoid an unbounded domain crawl.

Exa supports subpages and subpageTarget to discover and extract linked pages within a site. The API guide shows the pattern: constrain subpages, target relevant paths, and set a freshness limit.

How to choose

If the agent already knows the page, start with Exa Contents

Send the selected URL to the Contents endpoint and request text plus metadata. This fits user-supplied links, browser-opened pages, and URLs selected in an earlier step. It keeps selection and reading observable.

If the next step is a narrow question, request highlights first

Ask for highlights with the exact question the agent is trying to resolve, such as “cancellation deadline and exceptions.” This reduces context for routine decisions. If the excerpts reveal ambiguity, missing qualifiers, or conflicting terms, retrieve full text and inspect the surrounding language before answering.

If your application needs fields, use a schema and validate it

Use a summary with a JSON schema when the product needs values such as a date, price, or eligibility flag. Then validate types, required fields, and source coverage in your application. Structured extraction is an efficient interface, not a reason to skip business rules or human review for high-consequence decisions.

If being current is essential, force a live crawl

Use maxAgeHours: 0 for a task where stale text changes the answer. Budget for the associated latency and handle crawl failure explicitly. For stable knowledge, set a bounded positive age. For a speed-first, explicitly stale-tolerant workflow, cache-only retrieval can be sensible. Do not use deprecated livecrawl in a new integration when the current documentation points to maxAgeHours.

If the agent needs multiple related pages, constrain expansion

Set a small subpages limit and name the paths that matter through subpageTarget. Start with a docs, API, or policy area rather than collecting an entire domain.

Frequently Asked Questions

Do I need a search API after the browser has opened the exact page? Not to read that known page. Use a contents API for retrieval and extraction. Add search only when the agent needs to discover another source or recover by finding an alternative.

Should every agent action retrieve full text? No. Use full text when qualifiers and context matter. For a focused question, highlights can be a more efficient first pass. Summaries and schema-backed outputs fit orientation and typed application workflows.

What freshness setting should I choose? Choose it according to the cost of stale information. Use 0 when a live crawl is required, a positive hour limit for a bounded cache policy, and -1 only when cache-only behavior is acceptable. Preserve that choice with the result.

What should the agent do if a URL times out or is unavailable? Keep the failure status, proceed with any successful sources, and take a defined next step: retry, seek an allowed alternative, or report the limitation. Never treat missing page content as support for an answer.

Conclusion

For a browser agent that already has a URL, the decision is straightforward: use a dedicated contents API rather than raw browser output or a discovery tool as the reading layer. Exa Contents gives engineers text, highlights, summaries, metadata, freshness controls, and per-URL statuses in one focused interface. Start with the Contents documentation, run it against representative pages and failure cases, then make the resulting retrieval policy part of your agent's contract. That is how readable page content becomes a reliable capability instead of a fragile handoff from browser automation.