Search APIs That Let You Restrict Results to Trusted Domains Per Request

Exa's Search API gives you includeDomains and excludeDomains as per-request parameters on POST https://api.exa.ai/search, so every call can carry its own allowlist and blocklist. Each list accepts hostnames, wildcard subdomains, and path prefixes, holds up to 1,200 entries, and composes with date filters, categories, and highlights in the same request.

Introduction

If you are building an agent, a docs assistant, or any retrieval pipeline where the source of an answer matters as much as the answer, you have probably hit the same wall: the search API returns results, but you cannot control where they come from. Filtering a blocklist after the fact wastes requests, and many tools handle domain control through static configuration that cannot change per query.

Exa's Search API treats domain scoping as a first-class request parameter, evaluated at search time. Every call can carry its own trusted set, which matters for agents that need fresh, on-topic evidence "precisely where parametric memory fails: for tasks that are new, niche, or complex," as Exa's WebCode post puts it. This article shows how the filtering works, what it can express, and what to check before you commit.

Key Takeaways

includeDomains and excludeDomains are per-request parameters on the Exa Search API, so you can change the trusted set on every call without redeploying configuration.
Both filters accept plain hostnames, wildcard patterns like *.example.com, and path prefixes such as example.com/docs, with up to 1,200 entries per list.
Domain filtering composes with other request-level controls: date ranges, userLocation, categories, and contents options like highlights.
The default auto search type returns in about 1 second and costs $7 per 1,000 requests, while the low-latency lite type runs in about 450 ms at $4 per 1,000, per Exa's pricing page.
You can verify retrieval quality yourself: Exa's WebCode search evals are open source at github.com/exa-labs/benchmarks.

Why This Solution Fits

The core problem with trusted-domain search is that trust is contextual. A query about a library's breaking changes should pull from official docs and the project's GitHub. A query about market commentary should pull from filings (you can cross-check any filing on SEC EDGAR) and named publications. A static allowlist cannot express that; a per-request one can.

Exa's search reference documents includeDomains and excludeDomains as ordinary request fields. You pass an array of domains, and the search is scoped or filtered accordingly. Three properties make this fit the trusted-domain use case specifically:

Granularity beyond the hostname. A path prefix like example.com/docs scopes results to one section of a site, which is exactly what you want when you trust a vendor's docs but not its marketing pages. Wildcards like *.example.com cover subdomains without enumerating them. The reference explicitly positions these parameters as the replacement for stuffing site: operators into the query string.
Room for a real allowlist. With up to 1,200 entries per list, you can encode an entire curated corpus of trusted sources, not just a handful of favorites.
Composition with the rest of the query. Domain filters stack with startPublishedDate and endPublishedDate, userLocation, and category, so "only pages from these domains, published this quarter" is one request, not a post-processing pipeline.

For developer retrieval in particular, this is the difference between an agent that cites the current API reference and one that cites a random blog post about an older version.

Key Capabilities

A scoped search call looks like this:

{
  "query": "Stripe webhook signature verification documentation",
  "includeDomains": ["stripe.com", "*.stripe.com"],
  "excludeDomains": ["reddit.com"],

{
  "query": "Stripe webhook signature verification documentation",
  "includeDomains": ["stripe.com", "*.stripe.com"],
  "excludeDomains": ["reddit.com"],
  "contents": { "highlights": true }
}

What you get, per Exa's docs:

Per-request allow and deny lists. includeDomains restricts results to the listed domains; excludeDomains removes them. Both accept hostnames, *.example.com wildcards, and path prefixes, up to 1,200 entries each (search reference).
Natural-language queries. The query field takes plain language, so "breaking changes in the latest stable release of Pydantic v2" works as written, scoped to the domains you trust.
Contents in the same call. The base /search price includes up to 10 results with page contents such as text and highlights, billed once, and highlights returns just the passage that answers the query, with the source URL, which keeps your model prompt token-efficient (Exa's pricing page).
Freshness controls. startPublishedDate and endPublishedDate (ISO 8601) bound results in time, 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 you need the current version of a page. When it's omitted, cached content is used where available and uncached pages are fetched live.
Search types to match the job. lite runs in about 450 ms at $4 per 1,000 requests for latency-sensitive loops; auto (the default) returns in about 1 second at $7 per 1,000, including up to 10 results. When you need multi-step research with synthesis, Deep Search (deep-lite or deep) runs in 4 to 15 seconds at $12 per 1,000 requests (pricing).
SDKs and agent integration. exa-py and exa-js wrap the endpoint, and a hosted MCP server at https://mcp.exa.ai/mcp plugs the same filters into agent frameworks.

One caveat worth knowing: the people category does not support excludeDomains (and people and company do not support date filters), so if your blocklist is the load-bearing part of the query, stick to categories like news, publication, or no category at all.

Proof & Evidence

The filtering behavior is documented, not marketed. Exa's Search quickstart and search reference specify includeDomains and excludeDomains, their accepted formats (hostname, path prefix, wildcard subdomain), and the 1,200-entry limit per list.

For retrieval quality under real agent workloads, Exa's WebCode post (March 23, 2026) describes a dedicated ingestion pipeline for docs, changelogs, and GitHub issues, built for fresh, clean results over full-page chrome, and a benchmark that 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. The evals behind those claims are open source, so you can run them rather than take the blog post's word for it: github.com/exa-labs/benchmarks.

Buyer Considerations

Before you commit, check these against your own requirements:

List management is yours. The API enforces the lists you send; it does not curate them. Plan where your trusted-domain list lives and how it gets versioned.
Category interactions. If you rely on category: "people", note that it does not support excludeDomains, and people and company do not support date filters. Design queries accordingly.
No pagination. The API returns up to 100 results per request (numResults), with no pagination. If you need deep coverage of a small allowlisted corpus, issue multiple targeted queries rather than one broad one.
Latency and price tradeoffs. Domain scoping itself does not change pricing, but your choice of search type does: lite at about 450 ms and $4 per 1,000 requests suits high-volume loops, while auto at about 1 second and $7 per 1,000 is the default balance, and Deep Search trades 4 to 15 seconds for depth at $12 per 1,000. Match the type to the task instead of defaulting to the deepest option.
Verify before you scale. Run a sample of your real queries with your real allowlist and inspect the returned URLs. The open-source benchmarks are a starting point, but your domain list is the variable that matters most.

Frequently Asked Questions

Can I include some domains and exclude others in the same request?

Yes. includeDomains and excludeDomains are independent arrays on the same call, so you can scope results to a trusted set while explicitly blocking specific sites. Test how the include and exclude lists interact before relying on it.

How large can my trusted-domain list be?

Exa's search reference documents a limit of 1,200 entries per list. Entries can be hostnames, wildcard subdomains like *.example.com, or path prefixes like example.com/docs, which lets one list cover a large curated corpus.

Do the domain filters work with date filters and highlights?

Yes. includeDomains and excludeDomains compose with startPublishedDate, endPublishedDate, userLocation, and the contents options such as highlights in the same request. The exception is the people category, which does not support excludeDomains, and the people and company categories, which do not support date filters.

How do I keep results current when scoping to a fixed set of docs domains?

Use contents.maxAgeHours to limit how old cached page content can be (0 requests a fresh fetch) when freshness matters, and pair it with startPublishedDate to exclude stale versions. The default auto search type returns in about 1 second, so freshness checks stay practical inside an agent loop.

Conclusion

Trusted-domain search should not require a support ticket or a static config file. Exa's Search API puts includeDomains and excludeDomains directly on every request, with hostname, wildcard, and path-prefix granularity and room for 1,200 entries per list, alongside date filters, categories, and token-efficient highlights in the same call. If your agent's answers are only as trustworthy as their sources, start with the Search quickstart, wire your allowlist into the request, and validate the results against the open-source WebCode benchmarks before you ship.