Exa Search, Now Discoverable by Agents Over HTTP with x402

Search is one of the core primitives in modern agent systems.

When an agent is researching a topic, verifying a claim, gathering fresh information, or deciding what to do next, search is often the first external tool it reaches for. But while agents can reason about when they need retrieval, actually accessing premium search has still largely depended on human-centric onboarding: signups, API keys, billing setup, and preconfigured accounts.

That model works for developers. It does not map cleanly to autonomous software.

Today, that changes.

Exa now supports x402, making premium search discoverable and purchasable by agents at request time. Instead of requiring a human to provision access in advance, an agent can call an Exa endpoint, (ie /search or /contents), receive a 402 Payment Required response with pricing, pay, and continue, all in a single HTTP flow.

Find more information at their documentation, here.

The next generation of software will not just use tools. It will discover and pay for them, autonomously.

Agents increasingly operate in open-ended environments where they need to decide, in real time, which APIs, data sources, and services are worth using for a given task. In that world, the best products are not just the ones with the best output. They are the ones agents can discover, evaluate, and access exactly when needed.

Search is a particularly strong fit for this model.

It is episodic, high-value, and naturally invoked on demand. An agent does not always need retrieval. But when it does, retrieval often has an outsized impact on task quality. That makes search a natural pay-per-use primitive: valuable enough to pay for when needed, and modular enough to compose into a broader workflow.

With x402, Exa becomes easier to integrate into these autonomous workflows. Agents no longer need every tool provisioned ahead of time. They can discover pricing and settlement terms directly from the endpoint, make a decision, pay statelessly over http, and move on.

We’re excited to work with Exa to enable first-class support for autonomous tool discovery, economic reasoning, and purchase of agentic flows. 

Because the price is quoted before the request is fulfilled, agents can make an explicit cost-versus-value decision at runtime instead of treating premium retrieval as an all-or-nothing integration choice.

Most premium APIs today assume a human is somewhere in the loop before usage begins.

A developer signs up. They generate an API key. They attach a card. They choose a plan. Then, and only then, can software start making calls.

That flow made sense in the era of human-operated applications. But it creates friction for agents.

An agent may realize halfway through a task that it needs fresh search results to verify a source, compare vendors, research a market, or gather evidence before taking action. In that moment, the right interaction is not “stop and ask a human to set up billing.” The right interaction is “discover terms, pay, and continue.”

That is the gap x402 is designed to close.

Exa is a particularly compelling product to bring into this model because retrieval sits so close to the core loop of agent reasoning.

Agents need search when they are:

• gathering current information

• validating claims

• sourcing supporting evidence

• comparing options

• expanding context before taking action

These are not background features. They are often the moments that determine whether an agent succeeds or fails.

That is why search is one of the highest-leverage tool calls in agent systems, and why making premium retrieval easier to access has such a large downstream effect. Exa is already a strong retrieval product. With x402, it becomes easier to use as a default primitive inside autonomous workflows.

This is especially true because Exa exposes multiple search modes, including instant, auto, fast, deep-lite, deep, deep-reasoning, and deep-max, giving agents a clean runtime tradeoff between cost, speed, and depth.

Exa now supports x402, an open protocol that lets servers return payment requirements directly in HTTP responses.

In practice, that means an agent can:

1. Call an Exa endpoint

2. Receive a 402 Payment Required response with standardized payment terms

3. Inspect the accepted payment method, price, settlement target, and receipt format

4. Pay in USDC

5. Retry the request with proof of payment

6. Receive the result and continue the workflow

The 402 response includes a base64-encoded PAYMENT-REQUIRED header with pricing (e.g. “7000” = $0.007 USDC), network (eip155:8453 on Base), and payment recipient. The agent signs the payment and retries with a PAYMENT-SIGNATURE header, receiving results along with a PAYMENT-RESPONSE settlement receipt.

Instead of treating billing as a separate system outside the runtime, payment becomes part of the request flow itself.

That makes Exa available not only to developers integrating search ahead of time, but also to autonomous agents making decisions in the middle of a task. . It also means the same agent can use /search to discover relevant sources and /contents to retrieve page text, highlights, or summaries in the same pay-per-request model.

The most important part of this launch is not the payment rail. It is what Exa can now enable in real agent systems.

An agent researching a market calls /search, pays ~$0.007, extracts URLs, calls /contents for summaries, and synthesizes results, all without pre-provisioned access.  This enables:

• Autonomous research agents: An agent investigating a market, product category, or fast-moving topic can decide when premium retrieval is worth the cost, buy access on demand, and use Exa results to produce a higher-quality output.

• Tool marketplaces and OpenClaw-style environments: Premium search becomes a purchasable capability, not just a pre-integrated dependency. Agents can add retrieval to their tool belt dynamically, rather than relying only on tools provisioned in advance.

• Benchmark and evaluation workflows: Teams can run benchmark tasks that compare agent performance with and without Exa in the loop, then measure how retrieval impacts task completion, output quality, and cost efficiency.

• Multi-tool planning flows: Search becomes one step in a broader chain. An agent can search with Exa, browse or extract from the resulting pages, summarize the findings, and then take action based on the result.

• Enterprise-grade agent search: Internal teams can meter usage more cleanly, reduce provisioning friction for prototypes, and let agents access high-value tools without forcing every experiment through full account setup first.

As more software becomes autonomous, access models need to evolve with it.

Agents should be able to discover tools the way humans discover services on the web: at the moment of need, with clear terms, and with a straightforward path to use.

That is the broader significance of this launch.

Exa is not just exposing a premium search API. It is becoming available in a form factor that fits where software is going: open-ended, composable, runtime-native, and economically legible to machines.

This launch includes live documentation for Exa’s x402 support on /search and /contents, along with a working quickstart that shows the full request flow end to end. 

Developers can see how discovery works, how pricing is returned in the 402 Payment Required response, how payment is retried, and how to integrate the flow using reference examples in JavaScript, Python, and cURL. 

The Exa.ai documentation also includes pricing details, header references, and links to the full Search API and Contents API guides, making it easy to go from first request to production integration. Get started here.

Search is no longer something you provision ahead of time. It becomes a native, pay-as-you-go primitive inside the agent runtime.

This is what it looks like when native websearch becomes a first-class paid tool for autonomous software.