Migrating off the Bing Search API: a field-by-field replacement guide

Microsoft retired the Bing Search APIs on 11 August 2025 and decommissioned existing instances, so there is no v8 endpoint and no way to sign up for the old one. Every migration guide in this niche opens with that date and then jumps straight to a vendor list. The list is the easy part. The hard part is that the replacements are not the same product, and which one fits you depends entirely on which fields of the Bing response your code actually reads.

The short version: if your application parses webPages.value, pages through results with count and offset, and renders deepLinks in a UI, you want a SERP API, because a SERP API is the only category that reproduces that shape. If your application only ever pulled name, url and snippet into a prompt, you were using a search API as a text feed and you should move to an AI search API, which returns cleaner content per token at a lower price. If you were building a chat feature that answers questions from the web, Microsoft's own suggested destination, Grounding with Bing Search inside Azure AI Foundry, is closer to what you want than anything Bing's API ever gave you, and PPC Land reported its pricing at $35 per 1,000 transactions against retired Bing tiers of $6, $15 and $25.

This guide maps the request parameters and the response objects one at a time, then covers what changes downstream: ranking assumptions your code inherited without knowing it, and a cutover plan that catches the regressions before your users do. For choosing among the AI search APIs on their own merits rather than as Bing substitutes, see AI search APIs compared.

What Bing's retirement removed, and what quietly depended on it

The retirement covered more than Web Search. Bing News Search, Image Search, Video Search, Entity Search, Local Business Search, Spell Check and Custom Search went with it. Teams that used the Web Search endpoint with responseFilter=News and teams that used the dedicated News endpoint both lost their source on the same day.

The second-order effect is the one that matters for vendor selection. A large share of products that looked like independent search were Bing syndication underneath. When the API went away, the number of organizations running a general-purpose Western web index at scale that you can buy programmatically got very small. Brave's own AI Grounding announcement makes exactly this claim, positioning itself as the remaining independent and commercially viable search API at full web scale. Treat that as a vendor's framing of a real structural fact rather than a neutral measurement, but the structural fact holds: the set of genuinely independent indexes is short, and it is covered in independent search indexes for AI.

The pricing floor moved too. PPC Land's coverage of the shutdown put Bing's retired transaction tiers at $25 (S1), $15 (S2) and $6 (S3) per 1,000, against $35 per 1,000 for Grounding with Bing Search, which it framed as a 40% to 483% increase depending on which tier you were on. Whether that comparison is fair is arguable, since Grounding bundles model-side work the old API never did, but teams on the cheap tier did face a real cost jump.

Mapping the request: query, count, offset, market, freshness, safe search

Bing v7 took twelve or so query parameters. Most have an analogue somewhere; a few do not.

Two parameters deserve a note beyond the table. safeSearch defaulted to Moderate, so if you never set it you still had filtering, and moving to a replacement without one silently removes it. And responseFilter is the parameter most likely to break a migration quietly: a single Bing call that returned web results plus news plus images becomes two or three calls against different endpoints, with different rate limits and different failure modes, and the fan-out changes your latency budget.

Mapping the response: webPages, news, images, deepLinks and snippet semantics

Bing returned a SearchResponse envelope containing up to a dozen answer blocks: webPages, news, images, videos, places, entities, computation, timeZone, translations, relatedSearches, spellSuggestions, plus queryContext and rankingResponse. Almost every replacement returns a flat array of results. The envelope is the part that does not survive.

The snippet change is the one that bites hardest in practice and gets the least attention. Bing's snippet was a short, query-biased fragment sized for a search results page. Exa's and Tavily's default text output is much longer and written for a model to read. If you pipe an AI search API's text field into a UI component that expected two lines, every row overflows. If you pipe Bing's short snippet into an LLM, you were already giving it less context than these APIs provide, which is one reason answer quality can improve after migration even when the underlying index is weaker.

Four kinds of replacement and what each one preserves

Replacements sort into four categories, and the category decides the migration cost more than the individual vendor does.

SERP APIs. These return a search engine's results page as structured JSON. SerpAPI and DataForSEO both document Bing-specific endpoints, which makes them the only options that can return Bing's own results after the API shutdown. Serper.dev is Google-focused and priced around a dollar per thousand queries, and SearchAPI.io sells the same shape across multiple engines with framework integrations already written. This category preserves paging, sitelinks, related searches, locale targeting and the general concept of "position 1 through 10". It is the right destination if your product surfaces search results to a human.

AI search APIs. Brave Search API, Exa, Tavily, Linkup and You.com return ranked, LLM-ready content rather than a rendered results page. You lose paging, sitelinks and layout hints. You gain longer clean text, lower per-query cost and, in Brave's case, an index that is not derived from Google or Bing. This is the right destination if the consumer of the results is a model.

Grounding endpoints. Microsoft's Grounding with Bing Search, Brave's AI Grounding, and the answer modes of Perplexity and You.com return a written answer with citations instead of a result list. Different product, covered below.

Independent indexes with their own APIs. Mojeek runs its own crawl and index and sells API access. Its index is far smaller than Bing's, so it is not a general replacement, but it is a genuine independent source for teams that need results provably not derived from Google or Bing, and it is useful as a diversity signal alongside a primary provider.

Independent index or Google-derived: how your result set changes

Bing was its own index. That is the property most migrations lose without noticing, because most SERP APIs return Google results.

If you move from Bing to a Google-backed SERP API, your result set gets better on head queries and different on tail queries, and you have swapped one dependency on a hyperscaler's index for another. If you move to Brave, you get a genuinely separate index; Brave states it covers over 30 billion pages with over 100 million daily page updates as of March 2026, which is smaller than Google but is not a wrapper over anyone else. If you move to Exa, you have changed retrieval paradigm as well as index, since Exa ranks by embedding similarity rather than keyword match. A query like "error code 0x80070005" site:microsoft.com behaves well on a keyword index and poorly on a neural one; a query like "companies doing dataset licensing for model training" behaves the other way round.

There is also a supply-chain point that applies to SERP APIs specifically. SerpAPI has been in litigation with Google, and as of July 2026 a federal court dismissed Google's DMCA claims against it, with Google able to amend its complaint and a separate Reddit suit also naming the company. None of that is settled, and none of it currently stops the service operating, but if you are moving a production dependency it belongs in the risk column rather than being ignored.

Rewriting the ranking assumptions your application inherited

Code written against Bing tends to carry assumptions that were never written down.

Result 1 is authoritative. Bing's isNavigational flag existed because keyword engines reliably put the official domain first for brand queries. Neural retrieval does not guarantee that. If you had logic that treated value[0] as the canonical page for an entity, it needs an explicit domain check now.

Ten results is a page. Bing defaulted count to 10 because search results pages have ten blue links. Nothing about that number is meaningful to a model. If a model is the consumer, five results with 2,000 characters each is usually a better prompt than ten results with 150 characters each, so pick the count from your token budget rather than from Bing's default.

Snippets are short and stable. Any layout, token budget or truncation rule tuned to Bing's snippet length breaks against a replacement that returns 2,000 characters of extracted text. Measure your prompt size after migration; this is a common source of surprise cost increases that get blamed on the search vendor rather than the token bill.

totalEstimatedMatches means something. It was an estimate, it moved between requests for the same query, and it has no replacement. If you displayed it, stop.

Deduplication is the engine's job. Bing collapsed near-duplicate pages from the same domain. Not every replacement does, so a query that returned ten domains may now return four domains and ten URLs. If your downstream step assumes source diversity, enforce it yourself with a per-domain cap.

Grounding endpoints as a Bing replacement rather than a search endpoint

Microsoft's recommended destination is Grounding with Bing Search inside Azure AI Agents. It is worth being precise about what that is, because the naming invites the wrong expectation.

Grounding with Bing Search attaches web search to an agent. The model issues the queries, reads the results and returns an answer with citations, and the service's terms constrain how those citations are displayed. You do not get a JSON array you can store, rerank or page through. For a team whose Bing integration existed to answer user questions, this is a reasonable landing spot and removes work. For a team whose Bing integration fed a pipeline, an index, an alerting system or a UI with pagination, it is a different product wearing the same brand.

Brave shipped a comparable primitive, AI Grounding, on 5 August 2025, six days before the Bing shutdown, with a single-search mode Brave reports at around 4.5 seconds average and a multi-step research mode. Its published rate is $4 per thousand web searches plus $5 per million tokens, and Brave's announcement claims a 94.1% F1 score on OpenAI's SimpleQA. Linkup publishes a 91.0% SimpleQA F-score for its Deep tier. Both are vendor-published on their own runs, so read them as each vendor's account of its own system rather than as a head-to-head result.

The practical test is simple. If you can describe your requirement as "answer this question from the web", a grounding endpoint saves you the synthesis step. If you can describe it as "give me the ranked pages for this query", it does not, and you want a search endpoint.

Cutover plan: shadow traffic, diffing result sets, rollback

The integration is rarely what fails. The expensive failure is discovering three weeks later that a whole class of queries silently returns nothing.

Capture a week of production queries. Log the query string, the parameters you sent, and the response you got, before you change anything. If Bing is already off for you, use whatever you cut over to in a hurry as the baseline; you need a reference set either way.

Replay against every candidate in parallel. Same queries, same day, results stored side by side. This is the only evidence that matters, because your query distribution is not the distribution any published benchmark used.

Diff on three metrics. Overlap at ten (how many of the baseline's top ten URLs appear anywhere in the candidate's results), null rate (queries where the candidate returns nothing and the baseline returned something), and, if a model consumes the output, end-task accuracy on a labeled subset. Overlap below roughly half is not automatically a failure, since a different index legitimately finds different pages, but it tells you the change is user-visible and needs a human to look at samples.

Put the client behind an interface before you switch. One function that takes a query plus your normalized parameters and returns a normalized result list. Every vendor-specific field mapping lives inside one adapter. This costs a day and turns a future migration into a config change, which matters in a category where published rates and endpoint shapes both changed repeatedly through 2026.

Keep the old path runnable for two weeks. A feature flag and a fallback, not a git revert. Then delete it, because a fallback nobody exercises is a fallback that does not work.

Rate limits, quotas and contract terms to check before you switch

Four things to read before you commit, all of which differ from Bing's terms.

Requests per second, not just per month. Bing's tiers were sold on transactions per second as well as volume. Replacements vary widely, and free or entry tiers often cap concurrency low enough to break a batch job that ran fine on Bing.

Result caching and storage rights. Bing's terms restricted how long you could store results. Replacement terms differ, and some grounding endpoints impose citation-display requirements that constrain your UI. If you are building an index or a dataset rather than a live feature, read this clause first.

Per-endpoint billing. One Bing call with responseFilter covering web plus news was one transaction. Splitting that into two endpoints is two billed calls. Recalculate the unit economics on your real request mix, not on the headline per-thousand price.

Free tier shape. Several vendors moved from a free plan to a monthly credit allocation during 2026, including Brave. A credit allocation is fine for evaluation and not a production tier, so price the paid tier from the start.

Published rates in this category sit in the low single digits of dollars per thousand queries for standard web search across Brave, Serper.dev, Linkup and You.com, with Exa and the SERP APIs somewhat higher and deep-research tiers an order of magnitude above that. Rates changed repeatedly through the first half of 2026, so confirm the current number on each vendor's own pricing page before you budget rather than trusting any directory, including this one.

The decision is an inventory, not a vendor shortlist. Read your own code, list every field of the Bing response you actually consume, and check that list against the tables above. If deepLinks, offset or relatedSearches appear in it, you need a SERP API. If only name, url and snippet appear, you have more and cheaper options than you had before Bing shut down, and the migration is a net upgrade.