Two different meanings of “Bing Search API”
Microsoft’s Bing Search APIs were a product for integrating Bing web, image and other search data. Microsoft announced that the APIs would be retired on August 11, 2025, and directed customers toward Grounding with Bing Search in Azure AI Agents. That service supplies web grounding for AI agents; it is not the same interface as a general-purpose endpoint returning a normalized SERP response. Microsoft’s retirement notice is the primary source. Status checked October 22, 2026.
A Bing SERP API is a separate category: it requests a Bing results page and returns extracted result data. Serqo offers this through its own authenticated search API. It is not Microsoft’s retired service and does not promise drop-in compatibility with it.
Request Bing web results with Serqo
Use engine: "bing" and type: "web" on the shared search endpoint.
curl https://api.serqo.io/v1/search \
-H "x-api-key: $SERP_API_KEY" \
-H "Content-Type: application/json" \
-d '{"q":"privacy focused search","engine":"bing","type":"web","gl":"us","hl":"en"}' Read result items from data.results. Common fields include position, title, url, source and snippet; values depend on what the results page provides. See the Bing Search API reference for accepted parameters and response details.
What the request controls
q is the search phrase. gl sets the market country and hl the interface language. Bing currently supports desktop profiles only in Serqo; mobile device profiles are available for Google only. Unsupported parameters such as Google’s tbs time filter should be omitted for Bing.
Choose the right Microsoft product
If you need arbitrary public Bing results in a JSON response, use a SERP results provider and check its current engine support. If you need to measure a site you own in Bing, the Bing Webmaster API serves a different purpose: it exposes site, crawl, keyword and search performance data for registered sites. If your product needs an LLM to ground answers in live web data, review Microsoft’s current Grounding with Bing Search documentation and requirements.
Frequently asked questions
Can I still create a Microsoft Bing Search API subscription?
No. Microsoft’s retirement notice says the Bing Search APIs were retired on August 11, 2025. Grounding with Bing Search is a distinct Azure AI capability.
Does Serqo replace the old Microsoft API?
No. Serqo has its own request format, fields, authentication and supported search types. It returns Bing SERP data through /v1/search; applications must adapt to that contract.
Can I use the Bing Webmaster API for competitor keywords?
The Bing Webmaster API is for information about sites registered to your account, such as search and indexing performance. It is not an endpoint for retrieving arbitrary public Bing results pages.
Choose the Bing product that matches the task
The phrase “Bing Search API” is ambiguous after Microsoft retired its former Bing Search APIs. A SERP API retrieves the results visible for a public query. Bing Webmaster Tools and its API report on a site you manage, such as its search performance and indexing. Grounding with Bing Search is intended for grounding an AI agent. These products serve different jobs and expose different data; replacing one with another requires changing the workflow and response handling.
If you are migrating from an older integration, list the exact feature your application used before choosing a replacement. Was it general web search, image search, query suggestions, site analytics or grounding for a generated answer? Compare those requirements with a current product’s public documentation. Do not assume that a matching product name means the same endpoint, data rights or response schema.
Set a stable Bing request context
For a Bing web results snapshot, send engine: "bing" and type: "web". Include the search phrase in q, and set gl and hl when the market and language matter. Serqo currently uses desktop profiles for Bing. Parameters supported by Google are not automatically available on Bing; for example, leave Google’s tbs filter out of a Bing request.
Record the full request context with the result. A change from one country to another or a change in language can alter the page and should be treated as a separate observation. If you are comparing engines, keep the phrase, collection window and intended audience consistent, but report the Google and Bing series separately because their result layouts and ranking systems differ.
Interpret returned fields carefully
Read items from data.results and use the returned position, title, url, source and snippet when present. Do not assume every field exists on every item. Search pages can include different modules, and some result types expose additional groups in data.features. The API reference describes the current response contract; use optional-field handling in your parser.
When matching a result to a site, keep both the original URL and the normalized host. A URL may redirect, use a country-specific host, or point to a subdomain. Decide whether your report is about an exact URL, a page family or the whole domain. Save the original result so you can review a classification change without repeating the search.
Build a resilient collection workflow
- Validate the query and allowed parameter set before calling the API.
- Send the request from a server-side job with the key in the
x-api-keyheader. - Check the HTTP status and machine-readable error code.
- Store the request settings, response, collection time and request ID.
- Apply your own schedule, retention period and report definitions.
A single response answers what the search page returned for that request. It does not provide a complete archive, a webmaster report for a site, or a historical ranking series. Your application owns the schedule and storage if you need those capabilities.
Costs and operational limits
Successful searches use the applicable credit rate. Cached responses are free under the default rate rules, while failures and timeouts release the reserved credits. A repeated job can make many requests, especially if it checks many phrases, countries or pages. Estimate the number of requests before enabling a schedule and set a maximum batch size. See pricing and credit rules.
Keep retry behavior bounded. A temporary network failure can be retried according to the documented error response, but an unsupported parameter or invalid query needs a code change, not repeated attempts. Use request IDs when reporting a failed call, and avoid storing API keys in logs or result exports.
When this approach is a fit
A Bing SERP API fits tools that need to inspect publicly visible Bing results, compare result URLs, or collect market-specific search snapshots. It is not the right data source for measuring your own site's verified Bing performance; use Bing Webmaster tools for that. It is also not a general replacement for Microsoft's agent-grounding product. Choosing by task makes the data source and the limits easier to explain to users.
Separate current observations from historical claims
A SERP response describes a search result page at collection time. It should not be used as a proxy for Microsoft's first-party analytics or as evidence that a product feature is still available. For status questions about a Microsoft service, link to Microsoft's current product documentation and record when your team checked it. This keeps the guide useful when product names and offerings change.
If a migration has a fixed deadline, identify which systems still depend on the retired endpoint, then test replacements one use case at a time. A replacement may return a different schema, support different filters, or have different terms. Update parsing, data storage and user-facing descriptions together; merely changing the base URL is rarely enough.
Make reports explain their context
Show the query, engine, country and collection time next to any result comparison. If an operator changes the market or request type, the report should make that visible. Keep one chart or data series per engine so that a change in Bing's layout is not mistaken for a change in Google's results.
For debugging, retain request IDs and error codes, not API secrets. Avoid turning transient failures into missing-ranking values. A failed request means no observation was collected; it does not mean the target fell out of the results. Report collection coverage separately from ranking movement so users can see when a chart has gaps.
Continue with the Bing Search API reference or see how to build a rank tracking workflow.