What happened
Exa announced on November 12, 2026 that customers can run Search inside the European Union on the company’s main web index, using the same models as US customers. Its EU service currently covers the Search and Contents API endpoints and the auto and lite search types. The company says search results are at the same quality in the US and EU.
Exa describes the EU service as a second regional deployment built from the ground up. It replicated its main web index into the EU and says it maintains that copy in real time. Retrieval and inference run on Exa’s own GPUs in Stockholm. Page contents are retrieved and fetched through EU endpoints. The company says customer content—including queries, returned results, and page contents—stays in the EU, and EU teams have zero data retention by default, so request content is not kept.
The service is designed to fail closed rather than route requests across regions. An EU team’s API key works only with the EU endpoint, api.eu.exa.ai, and is refused elsewhere. If a feature is not available in the EU, Exa says it refuses the request before metering it rather than serving it from another region. Responses include an x-exa-processing-region: eu header that customers can use to audit request processing. Exa also says TLS connections to the endpoint terminate only in EU data centers, residency rules are checked in code review, and monitoring alerts if EU data appears outside the region.
Access requires a new EU team created by an Exa representative; a team’s region is set at creation and cannot be changed. Exa’s example uses the Python client with base_url="https://api.eu.exa.ai". The announcement says more search types are coming to the EU, followed by Agents, Websets, and Monitors. It does not state a separate price for the EU region.
What the archive adds
New Runtime’s earlier coverage of Parallel’s EU endpoint, published on 2026-10-22, described Search and Extract processing in the EU with zero content retention by default, while billing, metrics, edge logs, and URL lookup remained outside the region (EU Data Residency for the Parallel Search API). Exa’s announcement is a new event, not a restatement: it adds another search provider’s implementation, including region-locked keys and refusal rather than cross-region fallback.
Trend signal
This is consistent with the shift toward agent-ready software exposing bounded, auditable capabilities: Exa makes the processing region visible in each response and constrains which endpoint an EU key can use. The fit is partial—the announcement is principally about data residency, not a general capability interface. See Agent-ready software exposes capabilities.
Why now
Exa says a significant portion of its API traffic already comes from Europe and that customers had requested EU data residency. It frames the launch as a response to GDPR-related requirements and procurement, security, and regulatory requirements that can prevent companies from sending queries to a US service.
Connections to other events
The launch follows a similar regional-access change from Parallel, covered by New Runtime on 2026-10-22 (EU Data Residency for the Parallel Search API). Both providers offer EU processing for search-related APIs, but the described scope and controls differ: Parallel’s earlier note identified some billing and operational data outside the EU, while Exa explicitly describes region-locked keys, a processing-region response header, and rejection of unsupported requests before metering.
Why it matters
For teams building retrieval or agent products for European customers, data location can be a procurement gate before search quality or price even enters the evaluation. Exa’s design gives builders concrete controls to test: a key bound to one region, an endpoint tied to that region, a response header that can be logged, and rejection rather than quiet cross-region fallback. These controls can reduce the chance that a misconfigured client sends customer queries to a US service.
The boundary is not equivalent to every piece of account data staying in Europe. Exa says account and identity metadata and aggregated service metrics may be kept outside the EU. Teams should therefore map the actual data flows against their own requirements, test unsupported-feature behavior, and confirm contract and operational details with Exa before treating the service as compliant for a particular use case.
Limits and uncertainty
The announcement’s quality comparison is Exa’s own claim; it does not provide a measurement method, latency figures, or an independent evaluation for the EU deployment. The company does not specify the separate price, if any, for EU access. It also says account and identity metadata and aggregated service metrics may be kept outside the EU, without detailing their precise locations or retention periods. The announcement does not independently verify the implementation or explain how often EU requests may be refused because a requested feature is not yet available.
Skill to build now
If EU residency is a hard requirement, make endpoint region an explicit configuration rather than a deployment convention. Test with the EU key that calls to the US endpoint fail, log the x-exa-processing-region response header, and exercise a feature not supported in the EU to confirm the failure behavior before routing production traffic.
Reader takeaway
Exa’s EU launch is more than a regional hostname: the company says it runs retrieval and inference in-region and binds EU keys to the EU endpoint, with no fallback. That gives teams a useful deployment control for search workflows, but it does not settle every residency question: account metadata and aggregated metrics may still be outside Europe, so review the full data boundary before relying on it.