Cloudflare launches Web Search API to give AI agents real-time search

Cloudflare announced the Web Search API, in beta, on October 2, 2026, a way to give AI agents and applications access to live internet search. The idea, according to the official changelog, is to solve two classic problems for anyone building on an LLM: the model "guessing" a URL that doesn't exist, and answers based only on what went into training, already outdated by the day the product goes to production.

For developers in Brazil, this matters beyond the AI agent hype. If your product already uses AI Gateway to route calls to models, web search becomes just one more call within the same logging, caching, and billing pipeline you already monitor, instead of yet another loose integration with its own SDK and API key.

What the API solves in practice

Model updates have a training cutoff: asking about yesterday's event, a current price, or the latest version of a library produces an invented or outdated answer. The common workaround so far has been implementing RAG with a separate search provider, each with its own contract, authentication, and response format.

The Web Search API packages this search as a single call, with three providers to choose from at launch: Ceramic.ai, Exa, and Linkup. All three support Zero Data Retention (ZDR) for requests made through Cloudflare, and all have signed on to Cloudflare's own verified bot crawling standards. For anyone handling sensitive data or needing to justify compliance with the LGPD (Brazil's data protection law) in an audit, native ZDR across all three providers is a detail that saves you from having to chase down that guarantee case by case with each vendor.

One call, three providers

The call happens inside AI Gateway: search requests show up in the gateway's logs and are billed against AI Gateway credits at each provider's list price, with no markup from Cloudflare. You can also use your own API key for the provider instead of relying on Cloudflare's credit.

In practice, that means switching providers without rewriting the call logic: the parameter changes, and the rest of the observability pipeline stays the same. For anyone already running multiple models on the same AI Gateway, search joins the same cost and latency dashboard that already shows inference calls.

How to call the API

The REST example, straight from the changelog, shows the basic call:

curl https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/websearch/ \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "query": "What are some fun things to do in Salt Lake City as fall approaches?",
    "provider": "ceramic",
    "limit": 5,
    "options": { "gateway": { "id": "default" } }
  }'

For anyone who already has a Worker running with the AI binding, the call is even shorter, with no need to build a manual HTTP request:

const response = await env.AI.websearch({
  gatewayId: "default",
  query: "What are some fun things to do in Salt Lake City as fall approaches?",
  provider: "exa",
  limit: 5,
});

const results = await response.json();

The limit parameter controls how many results come back per query, and provider is the only field that changes when switching between Ceramic.ai, Exa, and Linkup. Anyone already using AI Gateway for other model calls will recognize the pattern: same gatewayId, same JSON response structure, no new SDK to learn.

What's still left open

The reference documentation, How to use Web Search API, covers usage details, but the changelog doesn't get into quality comparisons between the three providers or rate limits per plan. Since the API is in beta, it's expected that pricing, limits, and even the list of providers will change before the stable release.

There's also no public information so far about typical latency for each provider inside AI Gateway, nor about support for finer-grained search filters (date, domain, language) beyond the limit parameter. For anyone adopting it now, in beta, it's worth treating the choice of provider as something to revisit once Cloudflare publishes production usage data.

In practice, the angle Cloudflare is selling is less "one more search provider" and more "search as part of the same observability and billing pipeline you already use for AI." For teams that already route everything through AI Gateway, this tends to save the extra integration; for anyone not using Cloudflare as an AI layer, the Web Search API only pays off if the rest of the stack migrates there too.