Quick answer
Microsoft retired Bing Search APIs on August 11, 2025. If your application still calls a v7 endpoint or uses an Ocp-Apim-Subscription-Key header, treat it as migration work. First identify whether the feature needs Azure agent grounding, raw Bing SERP JSON, or a search-to-content pipeline.
What retirement means for an existing integration
Microsoft’s lifecycle notice says existing Bing Search API instances were decommissioned and new customer signups are no longer available. That makes an old v7 code sample useful only as evidence during an audit. It is not a current production setup guide.
Start by finding every dependency on the legacy API. The migration is not complete when a key changes. It is complete when each feature has a supported source of search data and its downstream behavior still makes sense.
Audit the legacy code before replacing it
Search repositories, deployment variables, notebooks, and internal runbooks for legacy endpoint and authentication patterns. The goal is to find use, not to run the retired endpoint.
from pathlib import Path
LEGACY_MARKERS = (
"api.bing.microsoft.com/v7.0/",
"Ocp-Apim-Subscription-Key",
"BING_SEARCH_API_KEY",
)
def find_legacy_bing_usage(root: str) -> list[tuple[str, str]]:
matches = []
for path in Path(root).rglob("*"):
if path.suffix.lower() not in {".py", ".js", ".ts", ".tsx", ".env", ".md"}:
continue
try:
text = path.read_text(encoding="utf-8", errors="ignore")
except OSError:
continue
for marker in LEGACY_MARKERS:
if marker in text:
matches.append((str(path), marker))
return matches
for path, marker in find_legacy_bing_usage("."):
print(f"{path}: {marker}")For every match, record four things:
- The feature that uses search results.
- The exact result fields the feature consumes.
- Whether the application needs raw search data or a model-generated answer.
- Whether it must read the pages returned by search.
That record prevents a migration from quietly replacing one type of data with another.
Choose the replacement architecture
There are three common paths. They solve related but different problems.
| Need | Appropriate path | Important boundary |
|---|---|---|
| An Azure agent needs web grounding for a model response | Evaluate Grounding with Bing Search in Azure Agent Service | Microsoft documents model output and citations, not developer access to raw web content returned by the grounding tool. |
| An application needs structured Bing results for its own feature | Use a maintained direct SERP API | Verify the exact JSON fields, locale controls, error behavior, and commercial terms. |
| An application must search and then read selected result pages | Use a SERP API plus a content-extraction stage | Search results and readable source text are separate stages with separate failure cases. |
Azure agent grounding is not a drop-in SERP endpoint
Microsoft describes Grounding with Bing Search as a tool for Azure AI Agents to incorporate public web data into a model response. The response includes citations, but the raw content returned from grounding is not exposed to developers. That can be a good fit when the feature is an Azure-hosted agent answer.
It is not the same requirement as rank tracking, collecting SERP JSON, feeding an independent retrieval pipeline, or storing structured result data for later analysis. Those uses need a direct data interface.
Direct SERP data needs an explicit contract
For a feature that needs raw Bing results, define the required fields before selecting a provider. A useful acceptance test covers the query, engine, country, language, result URLs, titles, snippets, error responses, retries, and the volume expected by the feature.
The Bing Search API product page documents SearchCans’ direct Bing path. It uses the same POST /api/v1/search endpoint as Google search and switches the engine with "t": "bing".
Search-to-content workflows need a second step
An agent often needs more than a title and snippet. It may need to open a result, extract usable text, keep source metadata, and decide what to cite. That is a separate extraction problem, even after the search integration is working.
SearchCans keeps the stages explicit:
- Bing Search API returns structured Bing results from
POST /api/v1/search. - Reader API accepts a selected URL at
POST /api/v1/urland returns extracted content.
Use browser rendering with mode: 1 only when a representative target page requires it. Start with the standard request, record the failure mode, and escalate only when the workflow needs it.
Rebuild a direct search-to-content workflow
This example replaces the legacy dependency with separate search and extraction calls. It does not assume every destination URL can be extracted, so production code should add bounded retries, logging, and a fallback policy.
import os
import requests
API_KEY = os.environ["SEARCHCANS_API_KEY"]
HEADERS = {"Authorization": f"Bearer {API_KEY}"}
def search_bing(query: str) -> list[dict]:
response = requests.post(
"https://www.searchcans.com/api/v1/search",
headers=HEADERS,
json={"t": "bing", "s": query},
timeout=30,
)
response.raise_for_status()
return response.json().get("data", [])
def read_source(url: str) -> str:
response = requests.post(
"https://www.searchcans.com/api/v1/url",
headers=HEADERS,
json={"t": "url", "s": url},
timeout=30,
)
response.raise_for_status()
return response.json().get("data", {}).get("markdown", "")
for result in search_bing("Bing Search API migration")[:3]:
source_url = result.get("url")
if source_url:
print(read_source(source_url)[:500])Before rollout, test the actual result shape for your selected request type. Handle empty result sets, timeouts, blocked source pages, and content that is not appropriate for your application’s access policy.
Validate the migration with representative work
Do not validate a replacement with one successful request. Use a small test set that reflects the feature people use:
- Include common queries, long-tail queries, and a query for each market you support.
- Compare the fields your application reads, not just the HTTP status code.
- Test the concurrency and retry behavior expected in production.
- Verify that result URLs can be handled by the next step of the workflow.
- Model the current cost of the complete workflow, including both search and any required extraction. Current SearchCans rates and Parallel Lane capacity are maintained on the pricing page.
Keep the request and response snapshots from that test. They make later provider changes easier to diagnose.
FAQ
Q: Is the old Bing Search API still available for a new integration?
A: No. Microsoft’s lifecycle notice says Bing Search APIs were retired on August 11, 2025, existing instances were decommissioned, and new customer signup is not available. Treat a v7 integration as a migration target.
Q: Is Azure Grounding with Bing Search the same as a raw SERP API?
A: No. Azure Grounding with Bing Search is designed for an Azure agent to use public web data when generating a model response with citations. A direct SERP API is appropriate when your own application needs structured search results and controls the next processing step.
Q: Can a direct Bing SERP integration also read result pages?
A: It can when the architecture includes an extraction stage. Search first to identify result URLs, then send selected URLs to a content-extraction service such as the Reader API. Test access and extraction behavior against the pages your application is permitted to process.
Final migration rule
Do not preserve a retired API’s shape merely because old code expects it. Preserve the user-facing feature, document the required data, and choose the narrowest supported architecture that produces it reliably.
