Exa vs Websets for Research: Raw Results or Built Lists?

TLDR: Exa runs two different research products. The Exa Search API takes a query and returns ranked results synchronously in one call. Websets takes a natural-language request plus criteria and asynchronously builds a verified list of entities, with enrichment fields for each one. One answers questions, the other builds lists, and picking the wrong one for the job is the most common way teams waste money on research tooling.

The comparison confuses people because both sit under the Exa brand and both "search the web," but they solve different problems at different latency and cost profiles. If you type a question and want results in one call, you want the search API. If you want a thousand companies that match a set of criteria, with fields filled in for each, you want Websets. This guide compares both using Exa's own documentation as the source, current as of September 2026, then maps where each one fits and where a general You.com Web Search API call or a cited synthesis fits into the same decision.

What Is the Exa Search API?

Exa's Search API is a synchronous endpoint. You POST a query to it and get ranked results back in the response, with options for how the search matches and what text comes back per result.

Query model: searches run in neural, keyword, or auto mode, per Exa's API reference, with neural matching queries to pages by meaning rather than exact terms.
Results: each result carries an id, url, title, and publishedDate, with optional contents such as page text, highlights, and summaries generated against your query.
Filters: the documented request includes date range filters, text inclusion and exclusion rules, and livecrawl timeout control for fetching fresh page content.

The shape to internalize: one call in, ranked results out, within seconds. The full contract is in the Exa search API reference.

What Is Exa Websets?

Websets is a different product: an asynchronous list builder. You define a natural-language search, a target item count, criteria every result must satisfy, and enrichment fields to populate for each accepted item. Websets then finds candidates, verifies each against your criteria, and only matching items become list entries, delivering results through the dashboard, API, or webhooks as they complete.

The behaviors documented by Exa that matter for planning:

Count is a target, not a guarantee. Websets keeps searching until it finds that many items that pass every criterion, or until it runs out of candidates. The final count can come in low.
It is asynchronous by nature. Small websets finish in minutes, while requests for a thousand or more items scan a much larger candidate pool and take significantly longer.
Free plan limits exist. Exa's documentation states the Free plan caps a webset at twenty-five verified results.
It is billed separately. Websets uses its own Websets credits, distinct from Search API credits, per Exa's plans and credits documentation.
It has list-shaped features: monitors for recurring searches, imports that enrich your own URLs, and webhooks for real-time delivery.

Exa's own guidance on their Websets overview is worth quoting in spirit: ask for a list, not an answer. Open-ended questions belong in Search.

Which One Should You Use for Which Job?

The decision framework is a table.

Question in, sources out, seconds: Search API. Grounding an agent, checking a fact, finding pages about a topic.
List in, verified entities out, minutes to hours: Websets. "Series A fintechs in Berlin with a female founder," "AI newsletters over ten thousand subscribers."
Recurring monitoring: Websets, via its monitors feature, because a saved search that re-runs on a schedule is a different job from a one-shot query.
Enriching URLs you already have: Websets imports, which run your enrichments on your own list.
Cited synthesis in one call: neither. A research API is the category built for that job, and You.com's Research API returns one-shot cited answers across sources.

Where Does a General Web Search API Fit In?

When the job is grounding, not list building, a general web search API is the leaner tool. The You.com Web Search API returns web results and, when the query has news intent, news results in the same response, with snippets by default and options for query-relevant highlights or full page contents per result. Freshness windows, domain steering, and pagination are documented parameters. That is a synchronous, per-query contract: one call, clean results, no criteria language and no waiting for a list to converge.

The honest framing is that the two products solve the opposite ends of the research spectrum. Websets is powerful precisely because it runs long, verifies against criteria, and enrichs. When you do not need any of that, you are paying in latency and credits for machinery your task never engages.

What Failure Modes Come With Each?

Over-constrained Websets. Exa's documentation is direct about this: a short or empty webset usually means the search is over-constrained rather than broken. Detection: relax criteria one at a time and watch the count recover, or split rare attributes into enrichment fields instead of hard criteria, which is Exa's own recommended pattern.

Count disappointment. You ask for five hundred matching entities, the run completes at one hundred forty, and downstream planning assumed the target. Detection: treat the requested count as a target in your own systems, the same way the product does, and alert on the completion ratio.

Search API freshness assumptions. A synchronous search can still return a stale page, especially when page text is involved. Detection: use the published dates that come back on results, and filter in your pipeline rather than trusting the default ranking for time-sensitive tasks.

Wrong tool for the question. Teams point Websets at open-ended research questions because it sounds more powerful, then wait hours for a list-shaped answer to a question-shaped request. Detection: if your request cannot be phrased as "entities that match X," it is a search or research job, not a webset.

Related Guides

FAQ

Is Websets part of the Exa Search API? They are separate products from the same company. The Search API is a synchronous endpoint that returns ranked results per query. Websets is an asynchronous list builder with its own credits, documented on Exa's Websets pages, and the two are billed independently.

Can I use Websets to ground an AI agent? Not for real-time grounding. Websets runs asynchronously and returns entity lists that pass criteria, which is the wrong shape for an agent that needs sources for the current question in seconds. Agent grounding is a synchronous search job.

Why did my webset come back with fewer items than I asked for? Exa documents count as a target, not a guarantee. The run stops when it runs out of candidates that pass every criterion. Relaxing criteria or moving rare attributes into enrichments is the documented fix, and "find more results" can extend an existing webset without starting over.

Which should I prototype with first? Start with the search API, because it is synchronous, cheap to evaluate per query, and answers the question "what does this vendor's web data look like." Move to Websets only when your actual deliverable is a list of verified entities with fields.