What Cloudflare's Web Search API changes for AI applications
Cloudflare's Web Search API, launched on 2 October 2026 and still in open beta, puts Ceramic.ai, Exa and Linkup behind one interface and sends those searches through AI Gateway. An application can now choose, watch and replace the search provider without tying that decision to the model that reads the results.
An AI application that needs current information is making two decisions that do not have to be made together: how it will obtain useful material from the live web, and which model will read that material and write a response. Those choices have often been bundled by a single vendor, but they can be made separately.
On 2 October 2026 Cloudflare launched a Web Search API that makes the split explicit. It is in open beta. An application sends a search query and receives a list of pages with titles, URLs and optional descriptions from one of three providers: Ceramic.ai, Exa or Linkup. Ceramic.ai is used if the application does not name a provider. The same call can be made over REST or from a Cloudflare Worker. Every request goes through AI Gateway; Cloudflare does not document a way around that.
The model and the search
A model knows what it learned while it was trained, plus whatever the application supplies when it is asked a question. Training stops at a date. If the application needs today's news, a changed API, current documentation, a recently published product, or any other live public source, that information has to be retrieved when the question is asked. Web search is one way to do that.
The company that provides the search does not have to be the company that provides the model. Cloudflare's API is built on that idea. The application chooses a search provider, receives structured results, and can pass those results to whichever model it already uses. The search step is a source of current context rather than a replacement for the model, and it does not guarantee that the model will use the context well.
One interface does not make the providers the same
Without a shared interface, an application is often written directly against one search provider's request format, authentication and response shape. Changing provider later then means changing application code, even if the job is still to search the web and hand the pages to the model.
Cloudflare normalises those results into a common structure: a URL, a title, and an optional description and other metadata when the provider returns them. The provider can be selected on each request. That reduces the work of switching the integration without making Ceramic.ai, Exa and Linkup interchangeable.
Cloudflare's own providers page already describes different search modes and different kinds of result. Ceramic.ai is positioned as a large independent index with long page descriptions. Exa is used in an automatic search mode and returns excerpts that match the query. Linkup is used in a fast search mode and returns sourced snippets without writing an answer of its own. The organisation still has to decide which of those behaviours is appropriate for the job. The common interface only means that decision is no longer also a rewrite of how the application sends a query and reads a response.
Search is part of how the application behaves
If an application retrieves the wrong pages, searches more often than expected, or starts costing more than planned, someone has to be able to see the search activity as well as the model activity. Cloudflare routes Web Search API calls through AI Gateway and says they appear in the same logs and analytics as model requests. Billing can use AI Gateway credits at each provider's list price with no additional Cloudflare markup, or the organisation can store its own provider key on the gateway so the provider bills that account directly.
That is useful because it lets an operator ask ordinary questions: what was searched, which provider was used, how often searches ran, whether a request failed, what the search layer is costing, and whether behaviour changed after an application update. It does not tell the operator whether the pages that came back were good.
Live pages are not the same as a correct answer
Cloudflare describes the product as a way to ground responses in live information instead of guessing URLs or relying on a model's training cutoff. That is a real improvement when the problem is missing current context. Search can give the application recent pages, identifiable source URLs, and material the model never saw during training.
It does not decide whether those pages are accurate, current, complete or suitable. Results can still be wrong, stale, thin, or in conflict with each other. The model can still misunderstand what it is given, combine sources badly, draw a conclusion the pages do not support, or treat commentary as if it were a primary source.
None of that is a failing of the API. Web retrieval gives the application evidence it did not previously have, and it still does not decide whether the evidence is good or whether the answer built from it is correct. Source URLs help an application show or check where a claim came from. Cloudflare also says participating providers have committed to its verified-bot crawling requirements, and that each result includes a link to the source. Availability of a URL is still not the same as quality of the page.
What beta status actually changes
The API is in open beta. The provider set, the common format and the gateway behaviour can still change. That matters most when search sits on the path a production system cannot do without: when a wrong or missing result changes what the application tells someone, or what it does next.
Before treating this path as dependable, an organisation should know which provider it is actually using, what happens when search fails or is slow, how costs will behave if the application starts searching more often, and whether the application can still operate if search is unavailable. Those are the same questions that apply to any other external service the application now depends on.
Most AI applications already depend on several services at once. Search can sit beside the model in that set, with identity, storage, tools, business systems and the application's own logic. Being able to choose and watch those pieces separately makes a system easier to change and to operate, provided the shared interface does not hide the behaviour that still belongs to the application: which sources are acceptable, what to do when search fails, what the search layer is allowed to cost, and what the model is allowed to conclude from the pages it is given. Connecting a model to other services without treating any one of them as the whole system is the usual AI integration problem, and this API is one more service in that picture.