Quick answer: The Bing Search API was Microsoft's long-standing way to get web, news, and image results programmatically, but Microsoft has been steering developers toward its Azure AI and agent-oriented search products rather than the classic standalone endpoints. If you need web search in an app today, do not assume the old API is a stable long-term bet: check Microsoft's current docs for its status, and evaluate dedicated search APIs (including link.sc) that are built for LLM and agent use. Do not rely on any specific pricing you read secondhand, including here.
For years, the Bing Search API was the default answer when a developer said "I need to add web search to my app and I do not want to scrape Google." It was reliable, well-documented, and it just worked. If you are landing on this page, something about that story has changed for you. Here is the honest state of things.
What the Bing Search API Was
At its core it was a set of REST endpoints that returned Bing results as structured JSON. You sent a query, you got back ranked results with titles, URLs, and short snippets, split across verticals:
- Web search: the main ranked web results.
- News search: recent news articles.
- Image and video search: media results with metadata.
- Entity and related endpoints: knowledge-panel-style structured data.
It was a snippet-and-link API. You got enough to show a results list or to feed a query into your own pipeline, but you did not get the full text of the pages. If you wanted page content, you fetched the URLs yourself.
Why Developers Are Asking About Its Status
Microsoft has been reshaping how it exposes search to developers. The direction has moved away from the classic standalone Search API and toward search that lives inside its Azure AI and Copilot-oriented tooling, where retrieval is bundled with grounding for AI applications rather than sold as a raw results endpoint.
The practical takeaway for you: the classic Bing Search API is not something to assume will exist in its current form indefinitely. Microsoft's own documentation is the only authoritative source on what is available, what is deprecated, and what the migration path is. Before you build on it or plan around it, read Microsoft's current docs. Anything you read elsewhere (including this post) can go stale fast.
I am deliberately not quoting prices, tiers, or shutdown dates here, because those are exactly the details that change and that you should confirm at the source.
Migration Concerns
If you have an existing integration on the Bing Search API, here is what tends to bite during a migration:
- Response shape changes. A replacement product rarely returns the identical JSON structure. Anything that parses
webPages.value[].snippetwill need rework. - Retrieval model changes. Moving from a raw results endpoint to a grounding-oriented AI search product can change what you get back: less "here are ten links," more "here is context for a model." That is a different integration, not a drop-in swap.
- Auth and SDK changes. New endpoints usually mean new keys, new SDKs, and new quota semantics.
- Behavioral drift. Ranking, freshness, and coverage can differ enough to change your app's output even when the code compiles.
The safe approach is to treat any migration as a chance to re-ask "what do I actually need from web search," rather than trying to recreate the old behavior one-to-one.
What You Probably Actually Need
Most teams reaching for a search API want one of two things:
- Grounding for an LLM or agent: current facts the model can reason over and cite.
- Web data for a pipeline: results plus the actual page content for RAG, extraction, or monitoring.
The classic snippet-and-link model serves neither cleanly. For grounding, snippets are too thin, so you end up fetching every URL anyway. For pipelines, you want the page text in a clean format, not raw HTML you have to parse.
That gap is why a wave of search APIs built specifically for AI use has appeared.
Alternatives for Developers Who Need Search Now
| Option | What it returns | Best for |
|---|---|---|
| Microsoft's current AI search products | Grounded, AI-oriented results | Teams already committed to Azure |
| Classic-style snippet APIs | Titles, URLs, snippets | Simple results lists, legacy parity |
| AI-first search APIs (incl. link.sc) | Search results plus full page content, LLM-ready | RAG, agents, research pipelines |
| Scraping search engines yourself | Whatever you can parse | Rarely worth it, see below |
A quick word on that last row: scraping search engine result pages directly is fragile, gets blocked, and carries terms-of-service risk. If you are tempted, read how to scrape search engines safely first, and then reconsider whether a purpose-built API is the saner path. For a broader comparison of AI-oriented options, the best search API for AI agents is a good next stop.
Where link.sc Fits
link.sc is a search API built for LLMs and agents, and the key difference from the classic Bing model is that it pairs search with a fetch endpoint that returns full page content, not just snippets. Search finds the URLs, fetch turns each one into clean markdown your model can read directly, without any HTML parsing on your side.
curl -X POST https://api.link.sc/v1/search \
-H "x-api-key: lsc_..." \
-H "Content-Type: application/json" \
-d '{
"q": "microsoft azure ai search grounding",
"engine": "google"
}'
Results come back under serpData.results, each with a title, targetUrl, and description. To get the full page content for a result's targetUrl (or any doc you already know you want), fetch it to markdown:
curl -X POST https://api.link.sc/v1/fetch \
-H "x-api-key: lsc_..." \
-H "Content-Type: application/json" \
-d '{"url": "https://learn.microsoft.com/some-doc", "format": "markdown"}'
link.sc has a free tier of 500 credits per month, so you can port a small integration over and see whether the full-content model changes how much glue code you need. Pricing lives at link.sc/pricing.
The Bottom Line
The Bing Search API was a great snippet-and-link service, and Microsoft is steering developers toward newer, AI-oriented search tooling. If your integration touched the classic API, treat this as a prompt to re-ask what you need rather than to clone the old behavior. Confirm the current status in Microsoft's docs, avoid trusting secondhand pricing, and if what you want is LLM-ready web data, look at a search API built for exactly that.
Need web search plus full page content, not just snippets? link.sc is built for LLMs and agents. Start free.