Bing Search API Retired: What Actually Replaces It

Copy this line to your agent to replace a dead search integration.

set up https://monid.ai/SKILL.md and use tinyfish /search to run a live web search

Microsoft retired the Bing Search APIs on 11 August 2025. This was not a price change or a tier consolidation. The endpoints were decommissioned, new signups were closed in February of that year, and code that still points at them now gets an HTTP 410 rather than JSON. If you built anything on api.bing.microsoft.com, it stopped working on a date somebody else picked. That is the part worth thinking about, more than the replacement itself. Monid is the OpenRouter for agent tools: one key and one balance across many providers, so the next retirement costs you a parameter instead of a rewrite.

Why did the Bing Search API go away, and what broke?

Bing Search was retired as a product, not migrated. Microsoft's lifecycle announcement is explicit that the F1 and S1 through S9 Bing Search tiers, along with F0 and S1 through S4 Bing Custom Search, were decommissioned and are no longer available to new or existing customers. The recommended path was not another search endpoint but Grounding with Bing Search inside Azure AI Agents, which is a different product with a different shape.

The timeline is the lesson, not the outage

Three dates matter, and they were spread across six months. New Bing Search resources could no longer be created in Azure from February 2025. The formal retirement notice landed on 13 May 2025. The endpoints stopped responding on 11 August 2025.

Anyone watching the Azure portal saw the first date. Anyone reading release notes saw the second. Everyone else found out from an alert. That gap is the actual risk in a single-vendor search dependency: the notice period is real, but it only helps if the dependency is somewhere you look, and a search call buried three layers into a retrieval pipeline is not somewhere you look.

A 410 breaks differently from a 500

An HTTP 410 means gone, permanently, and that is worse for most codebases than an outage. Retry logic treats a 500 as transient and backs off, which is correct. A 410 is not transient, so a retry loop turns one dead call into a stack of dead calls, and the failure surfaces as latency and burnt tokens rather than as a clear error.

That is the specific way an agent pipeline degrades: it keeps working, the answers get worse, and nothing in the logs says search is dead. One user on r/LocalLLM described the adjacent symptom, extracting web content for a local model wasting a large amount of tokens before anything useful comes back.

Single vendor versus a routed catalogue: what actually differs

The pattern here is not that one is better. It is that the cost of being wrong is paid at different times: a single vendor is cheaper to adopt and more expensive to leave.

📖 See also Amazon's PA-API Retires in 2026: How to Move to Monid, which is the same shape of problem with a different vendor.

How do you move a search integration off a retired API?

Replacing a search call is three steps, and the first two are free. The order matters because the schema decides how much of your parsing code survives, and you can read the schema before you spend anything.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-key> -l main

Step 1. Find what exists before choosing

What it does. Searches the catalogue semantically and returns ranked endpoints with provider, description, billing shape and a verified tag, so you are choosing from what is live today rather than from a blog post.

The endpoints. Discovery covers the whole search category, which currently spans neural search, keyword search, browser-rendered search and search-plus-scrape in one call.

The call.

monid discover -q "web search results"

What comes back. A ranked list. Running it on 2026-08-20 returned context.dev/web/search, tinyfish/search, exa/search, octen/search and surf/search/web among others, each with its billing shape attached.

What it costs. Nothing. Discovery and inspection are both free, which is what makes it reasonable to compare five options before writing any code.

Step 2. Read the schema, then decide what your parser keeps

What it does. Returns the full input schema, the billing shape and the docs URL for one endpoint, so you can diff it against the response shape your code already expects.

The endpoints. tinyfish/search is the closest thing to a like-for-like Bing Web Search replacement: it takes a query and returns ranked results.

The call.

monid inspect -p tinyfish -e /search

What comes back. Verified 2026-08-20: results carry position, title, url, site_name and snippet. Inputs include query, a domain_type switch across web, news and research_paper, geo and language targeting through location and language, allow and block lists through include_domains and exclude_domains, a freshness window through recency_minutes, calendar bounds through after_date and before_date, and zero-indexed paging up to page 10.

Two of those have no Bing equivalent. recency_minutes is a relative freshness window rather than a date filter, which is the right shape for "what changed in the last hour". purpose takes a short statement of the task the results are for and uses it as a ranking signal, which is useful when an agent is searching on behalf of a specific job.

What it costs. Nothing to inspect. The endpoint itself is priced per call.

Step 3. Run one query and diff the output

What it does. Executes the search and bills your balance at the price already shown, with no separate signup for the underlying provider.

The call.

monid run -p tinyfish -e /search \
  --query '{"query":"bing search api retirement","domain_type":"news","recency_minutes":1440}' -w

What comes back. Ranked results with publisher and date attached, because domain_type: news adds those two fields. Note the flag: queryParams in the inspect output maps to --query, not -i. Getting that wrong is the most common first-run error and it returns a schema complaint rather than a charge.

What it costs. This endpoint is browser-rendered and priced per call, and per call is the shape you want here: one query, one charge, regardless of how many results come back. Current figures are on monid.ai/tools, and inspect shows the exact number before anything bills.

What are the best alternatives to the Brave Search API?

The honest answer is that the question has four answers, because "search API" describes four different jobs that happen to share a name. This matters for the Bing reader too: whichever vendor you are leaving, picking the replacement by brand rather than by job is how you end up migrating twice.

If you want ranked links and nothing else

Use a plain SERP-shaped endpoint. tinyfish/search returns position, title, URL, site name and snippet, and it is browser-rendered against the live web rather than served from a cache, so pricing pages and breaking news are current at query time. api.kadec0.xyz/v1/serp covers the same job with a different trick: it lets you pin the backend engine, choosing Brave, Yahoo or Yandex explicitly rather than accepting a rotation.

That last one is the direct answer for anyone leaving Brave specifically. The index is still reachable, just through a different door.

If you want the page contents, not the links

Search and extraction are separate steps, and paying for them separately is usually right. But context.dev/web/search collapses them: it searches and optionally scrapes each result to Markdown in one call, which saves a round trip when the agent was always going to read the pages anyway. octen/search does the same job with a different billing shape, charging per call by default and switching to per-token billing only when full content is enabled.

The rule of thumb: if fewer than half the results get read, keep the steps separate. We went through the numbers in a free API to extract page content for RAG, where a Wikipedia page came back at 74,552 characters through the scraping route and 689 through the official one.

If you want meaning rather than keywords

exa/search is neural search, which matches on what a page is about rather than which words it contains. blockrun.ai/api/v1/exa/search exposes the same engine with a category filter across company, research paper, news, PDF, GitHub, tweet, personal site, LinkedIn profile and financial report, which narrows by document type before ranking rather than after.

If your agent should choose at runtime

An agent that can call discover picks the endpoint per query rather than per deployment, so a news question goes to the news corpus and a paper question goes to the research corpus without you writing that branch.

📖 See also Which MCP Server Gives an AI Agent Live Web Data? and The Best Web Search API for AI Agents in 2026

Which endpoint should I use for which job?

Every row verified with monid inspect on 2026-08-20. The billing column is the shape, not a figure, because the shape is what changes how you architect and it does not go stale.

What does a search integration actually cost?

Less than the migration did, which is the uncomfortable part. Work it in three stages.

Discovery and inspection are free, so comparing six endpoints and reading all six schemas costs nothing at all. That stage used to be a week of signups.

A single query on a per-call endpoint is a fraction of a cent, and one of the endpoints above is currently free at the point of use. A realistic retrieval workload, a few thousand searches a month behind an agent, lands in single-digit dollars. The variable that moves the number is not the search step but whether you also pull page content: extraction is where per-token and per-result billing appear, and where a careless full_content: true turns a cheap call into an expensive one.

Prices are on monid.ai/tools, and because inspect is free the exact figure is visible before a single call bills. That is the point of a pay-as-you-go balance: access costs nothing until it is used, so an agent can carry the whole catalogue and still pay only for the calls it makes. We laid out when metered loses to a subscription in pay per call versus subscription, and the honest answer there is that steady predictable volume favours the subscription.

When should you not use Monid?

If Microsoft's own migration path fits, take it. Grounding with Bing Search inside Azure AI Agents is a supported Microsoft product with Microsoft's index behind it, and if your workload and your compliance story are already written against Azure, adding a second vendor to save a small amount per call is a bad trade. The catch is that it is a grounding feature for an agent, not a search API returning ranked links, so it replaces Bing Search only if what you wanted was grounded answers.

If you need one specific index and only that index, go direct. Nobody should route Google Search through an aggregator when the official Custom Search JSON API covers the use case, and the same holds for any provider whose free tier already covers your volume.

If your search volume is high, steady and unchanging, a committed contract with one vendor will beat metered pricing. Metered wins on bursty and unpredictable workloads and on the long tail of endpoints you call rarely. It does not win on a flat, well-understood load.

And if you need Bing's index specifically, no route gives you the retired product back. What is available is other indexes, reached other ways.

Conclusion

The Bing Search API is not deprecated, it is gone, and there is no drop-in replacement because Microsoft did not ship one. What replaces it depends on which of four jobs you were doing: ranked links, links plus page contents, semantic retrieval, or letting an agent decide per query. Pick by job and the migration is one endpoint and a field mapping. Pick by brand and you will do it again.

The thing that matters more than the choice: the reason this hurt was not that Bing went away, it was that the dependency was hard-coded in a place nobody was watching. Whatever you move to, the parameter is worth keeping soft. An endpoint name in config survives a retirement. An endpoint name in a client class does not.

The free next step is genuinely free. Run monid discover -q "web search results" to see what exists today, monid inspect on the two that look closest to read their schemas and current prices, and only then one small paid run to diff the output against what your parser expects. Start at monid.ai.

FAQ

Last updated August 2026.