Yes: One Search API Can Handle Vague Natural-Language Queries and Exact Matches

Yes. The Exa Search API is built on embeddings, so it handles vague natural-language queries like "open source Rust libraries for vector similarity search" directly. For exact matches, you get precision through tightly scoped queries plus filters such as includeDomains, date ranges, and categories, all on the same endpoint, so one API covers both query styles.

Introduction

Many tools force a choice. Keyword engines match tokens but fall apart when a user types a fuzzy, half-formed question, while vector databases drift when you need a specific page, domain, or phrase to come back. Exa closes that gap: its index is embeddings-native, so you send a natural-language query to POST https://api.exa.ai/search and get ranked results with titles, URLs, and published dates, up to 100 per request. That is the semantic mode, and it is the default behavior, not a premium add-on.

On the keyword side, Exa does not expose a separate boolean keyword mode, and it does not need one. Instead it exposes precision controls on the same endpoint that get you exact-match behavior in practice: scope results to specific domains (including path prefixes like example.com/docs), pin publication dates, restrict to a category such as company or publication, and phrase the query with the exact terms you need. Exa documents quoted-phrase restrictions in queries. Check notices for RESTRICTIONS_RELAXED, and verify returned content when exact matching is essential (Search best practices).

Key Takeaways

Exa's Search API is embeddings-based by default: one natural-language query string, ranked results, no query rewriting on your side.
There is no separate keyword mode flag. Exactness comes from precise query phrasing plus filters: includeDomains / excludeDomains (up to 1,200 entries, path prefixes supported), startPublishedDate / endPublishedDate, and category.
Four recommended search types let you trade speed for depth: lite (~450 ms, $4 / 1k requests), auto (~1 second, $7 / 1k, the default), deep-lite (~4 seconds, $12 / 1k), and deep (4 to 15 seconds, $12 / 1k).
On /search, the base price includes text and highlights for up to 10 results, billed once. 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).
You can test both query styles today: Exa's Free tier includes $10 in credits every month (up to 2,500 Lite searches), plus a one-time $10 onboarding bonus, with no payment method required (see Exa's pricing page).

Why This Solution Fits

If your product has two query surfaces, a search box where users type questions in prose and a power-user path where they need a specific document, you would normally wire up two systems. With Exa you wire up one.

The semantic path is the reason Exa exists. Queries like "Stripe webhook signature verification documentation" or "breaking changes in the latest stable release of Pydantic v2" are examples from Exa's own docs, and they are the kind of query token matching handles badly: the words in the query are not the words on the page. Embedding retrieval finds the page that is about the thing, an approach the Dense Passage Retrieval paper found can outperform sparse retrieval such as BM25 for open-domain question answering.

The exact path is where the filters earn their keep. If your agent must only ever cite official documentation, send includeDomains: ["docs.stripe.com"] and every result comes from that domain. If you need a specific window, startPublishedDate and endPublishedDate take ISO 8601 dates. If you only want papers, category: "publication" restricts the search to Exa's index of 350M publications. Each is a field on the same /search call, documented in the Search API reference. That combination, neural retrieval plus hard scoping, is what "exact match" means for most real applications: a guarantee about where results come from and when they were published.

Here is one runnable request that combines a vague query with scoping (REST bodies use camelCase; the Python SDK uses snake_case keyword arguments):

curl -X POST https://api.exa.ai/search \
  -H "x-api-key: $EXA_API_KEY" \
  -H "Content-Type: application/json"

curl -X POST https://api.exa.ai/search \
  -H "x-api-key: $EXA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query": "open source Rust libraries for vector similarity search", "type": "auto", "numResults": 10, "contents": {"highlights": true}}'

The response returns results[].url, results[].title, results[].publishedDate and results[].highlights, per the Search reference. Note that publishedDate is an estimate parsed from page HTML, not a guaranteed exact date.

Key Capabilities

Natural-language queries as the primary interface. One query string, no keyword extraction step. Results return ranked, with numResults up to 100.
Four search types on one endpoint. lite for latency-sensitive paths (~450 ms, $4 / 1k requests, cache-only), auto as the balanced default (~1 second, $7 / 1k), and the deep types (deep-lite ~4 seconds and deep 4 to 15 seconds, both $12 / 1k) when the task needs research and synthesis. The ~450 ms and ~1 second figures are typical latencies in the docs; auto measured about 1.5 seconds median (1,502 ms p50) in Exa's SealQA comparison benchmark (runs July 8 to 24, 2026) (versus/parallel). Neither is a response-time guarantee.
Domain and date precision. includeDomains / excludeDomains accept hostnames, wildcard subdomains, and path prefixes; date filters bound results by publication date. Note that the company and people categories do not support date filters, and people also does not support excludeDomains.
Content in the same call. contents.highlights returns just the passage that answers the query, with the source URL. Text and highlights are included in the base price for up to 10 results. Exa reports that 500 characters of highlights match the retrieval accuracy of the first 8,000 characters of page content, which matters when results feed an LLM prompt (highlights docs).
Structured synthesis when you need it. outputSchema returns a generated output.content with field-level citations in output.grounding, adding about 2 seconds of latency. It is not accepted on lite; use auto or a deep type.
SDKs and MCP. exa-py and exa-js SDKs, plus a hosted MCP server for agent frameworks.

Proof & Evidence

The load-bearing claim is that embeddings-based retrieval over a fresh, curated index actually performs, and Exa publishes checkable evidence rather than asking you to take it on faith.

The WebCode evals for coding-agent search are open source at github.com/exa-labs/benchmarks, so you can run the retrieval quality measurements yourself rather than trusting a marketing page (WebCode blog post, March 2026). This is Exa's own open-sourced eval repo, not an independent one.
On publication search, Exa reports 86.4% recall at 0.578 s mean latency on the Tip-of-the-Tongue track in Exa's benchmarks repo, where it reports substantially higher recall than widely used general and academic search baselines (SOTA Search Over Academic Publications, July 2026). That is the semantic mode doing exactly this job: finding a known item from a vague description.
Latency figures come from the Search quickstart and Exa's benchmark page (updated October 19, 2026); pricing comes from the pricing docs.

Buyer Considerations

No boolean keyword flag. If your requirement is literally a mode: "keyword" parameter, Exa does not have one. In practice, scoped neural search (exact domains, exact dates, exact phrasing) is what most agent and in-product search workflows need.
No pagination. You get up to 100 results per request; there is no page-two. Plan result counts accordingly.
Category limitations. company and people searches do not support date filters, and people does not support excludeDomains, so exactness controls are narrower there.
Latency is mode-dependent. If your exact-match path is on a real-time surface, use lite (~450 ms); if it feeds a research pipeline, the deep types buy you synthesis at 4 to 15 seconds.
Costs scale with depth, not query style. Semantic and precision-scoped queries cost the same: $7 / 1k requests on auto and $4 / 1k on lite, so there is no penalty for mixing query styles in one product.

Frequently Asked Questions

Does Exa have a keyword or exact-match mode?

Not as a separate mode flag. Exa's search is primarily neural (embeddings-based). You achieve exact-match behavior by phrasing queries precisely and constraining results with includeDomains, date filters, and category on the same endpoint. Exa documents quoted-phrase restrictions in queries; check notices for RESTRICTIONS_RELAXED, and verify returned content when exact matching is essential. The deprecated includeText and excludeText parameters are replaced by "the terms in the query itself" (Search best practices).

How does it handle vague natural-language queries?

Directly. The query field accepts full sentences and descriptions, and the embedding index ranks pages by semantic relevance. Example queries from Exa's docs include "open source Rust libraries for vector similarity search" and "breaking changes in the latest stable release of Pydantic v2".

What does it cost to run both query styles?

The same. Search is priced per request by type: $4 per 1,000 requests for lite, $7 per 1,000 for auto, and $12 per 1,000 for the deep types (deep-lite and deep). The base price includes text and highlights for up to 10 results; results above 10 cost $1 per 1,000 results, and AI page summaries are $1 per 1,000 pages.

Can I try it before committing?

Yes. Exa's Free tier includes $10 in credits every month (up to 2,500 Lite searches), plus a one-time $10 onboarding bonus, with no payment method required (see Exa's pricing page). The quickstart gets a first semantic query running in minutes.

Conclusion

So, are there search APIs with both a semantic mode for vague natural-language queries and a path to exact matches? Yes, and Exa answers it this way: embeddings-based retrieval as the default, with domain, date, and category filters delivering the precision a keyword mode would otherwise provide, on a single /search endpoint with typical latency from about 450 ms (lite) to 4 to 15 seconds (deep). If you are evaluating APIs for a product that needs both query styles, start with the quickstart, run your own vague and exact queries against the free credits, and check the open-source benchmarks repo to verify retrieval quality on your own terms.