← Back to Blog

Agents

Cloudflare Web Search API in AI Gateway: What Agent Builders Should Know

Oct 5, 2026·5 min read·By Rahish Saifi

Cloudflare Web Search API in AI Gateway: What Agent Builders Should Know — cover illustration for AI with Rahish blog

On October 2, 2026, Cloudflare announced a Web Search API integrated with AI Gateway, its control plane for model inference. Launch partners include Ceramic.ai, Exa, and Linkup. The goal is straightforward: give agents a proper search step—like a human opening a search engine—instead of guessing URLs and firing blind curl requests that often return 404s.

If you have shipped agents, you have seen that failure mode. A model hallucinates a documentation path, fetches garbage, and confidently answers anyway. Web search as a first-class API, billed and logged alongside your LLM calls, is Cloudflare’s answer—and it reflects where the industry is heading for anything that touches live information.

What Cloudflare launched

From the announcement and Cloudflare Web Search API documentation:

  • Web Search API returns structured web snippets you can inject into model context—grounding responses on information after the model’s training cutoff.
  • AI Gateway integration: Search calls appear in the same observability logs as inference; usage draws from your AI Gateway credit balance.
  • Provider choice: Specify a provider (e.g. ceramic, exa) per request.
  • List pricing: Cloudflare offers search at list API pricing from partners without additional markup.
  • Bring Your Own Key (BYOK): Supported for web search providers, similar to model providers.
  • Zero Data Retention (ZDR): Cloudflare’s provider table lists ZDR support per vendor (Ceramic.ai, Exa, and Linkup are marked as supporting ZDR).
  • Provider pricing (list rates via AI Gateway credits): Ceramic.ai at $0.25 per 1,000 requests (default provider), Linkup at $5.00, and Exa at $7.00 per 1,000 requests—no markup on top of list API pricing when paying through AI Gateway.
  • Access paths: Direct REST API, Workers bindings (env.AI.websearch), and manual tool orchestration examples in the blog post.

Cloudflare also notes upcoming Server Tools in AI Gateway—built-in tools so you spend less time wiring harness code—with web search among the first.

Why “guess the URL” breaks agent reliability

Static knowledge in weights works for stable concepts; it fails for API changelogs, security advisories, pricing updates, and news. RAG over your own corpus does not help when the answer lives on someone else’s site.

Search-backed context closes that gap if you treat it as infrastructure, not a prompt hack:

  1. Retrieve with a query the model (or a router) formulates.
  2. Inject snippets with source URLs into the message thread.
  3. Generate an answer that cites or aligns with those snippets.
  4. Log the query, provider, and results for debugging and compliance.

Cloudflare’s framing—that agents should browse like humans—is the right mental model. The anti-pattern is skipping retrieval and hoping parametric memory encodes this week’s release notes.

Crawler standards and why they matter to you

Cloudflare emphasizes that launch partners commit to its bot crawling standards: crawlers must meet Cloudflare’s publicly stated requirements for verified bots, and responses must include a link to crawled content. The post ties this to robots.txt respect and creator control over how content is used.

For product teams, this is not abstract ethics—it affects whether search results are stable and licensable in commercial agents. If your agent stack depends on search, prefer providers that document crawling behavior and source attribution. Your legal and security reviewers will ask anyway.

Integration patterns

REST from an existing backend

Cloudflare documents a POST to https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/websearch/ with bearer auth, a query, provider, limit, and optional gateway.id in the payload. This fits mobile apps, on-prem services, or any stack that is not on Workers.

Workers binding

On Workers, env.AI.websearch({ gatewayId, query, provider, limit }) is the one-liner entry point—useful when your agent already runs at the edge next to AI Gateway.

Tool-calling loop

The blog shows a full pattern: model emits a web_search tool call, your worker executes env.AI.websearch, then passes JSON results back as a tool message before a final completion. That is the same orchestration you would use with any search vendor; the difference is unified billing and logs under AI Gateway.

If you are comparing frameworks for RAG and tools, see LangChain vs LlamaIndex—the orchestration concepts transfer even when the search backend changes.

How this compares to rolling your own search tool

You could integrate Exa or another provider directly. Cloudflare’s pitch is consolidation:

  • One control plane for models, search, rate limits, and access policies.
  • Shared observability when a user complaint traces to “bad retrieval” versus “bad generation.”
  • BYOK if you already have enterprise contracts with a search vendor.

Trade-offs remain: you add a Cloudflare dependency; you must still eval which provider returns the best snippets for your domain (code docs vs general news vs commerce).

Practical takeaways for builders

1. Make search a required step for time-sensitive tasks

Route questions about “latest,” “today,” or specific product versions through search automatically. Do not rely on the model to self-nominate retrieval.

2. Cap limits and budget per session

Each search call spends credits. Agent loops can spam queries. Set per-task search budgets and deduplicate identical queries within a session.

3. Store sources in the user-visible answer

Partners are expected to return locators for crawled content—use them. Citations improve trust and make hallucinations easier to catch in review.

4. Plan for Server Tools

If Cloudflare ships native server tools, your custom tool glue may shrink—but your eval harness should not. Keep golden questions that require fresh web facts and run them after any platform change.

Bottom line

Cloudflare’s Web Search API is a pragmatic fix for a common agent failure mode: guessing URLs instead of searching. Wrapped in AI Gateway, it treats retrieval as part of inference operations—logged, billed, and governable like model tokens.

If your agents answer questions about the live web, test this stack against your current search integration on latency, snippet quality, and cost. The launch partners are a starting lineup, not the end of the market—but the control-plane pattern is likely here to stay.