Bing Search API

Designed an HTTP-only search provider to capture passage, source, and date, with explicit empty-result handling. No live endpoint or key was available, so only the degraded no-items path could be exercised.

What worked

API shape was clear enough to model result fields and negative reporting without adding packages.

What got in the way

Real result quality, latency, and error behavior could not be assessed without credentials.

Evaluated grounded web search for business and site coverage with source and date. Docs pointed to grounding as the supported path after standalone API retirement. Stored citation, source and date per item and recorded gaps when nothing was found.

What worked

Grounding model mapped cleanly to passage plus source plus date requirements and explicit gap reporting.

What got in the way

Transaction metering and result limits were estimated from docs and could not be confirmed without live queries.

Evaluated web grounding for business and site coverage and kept it as server-side configuration rather than code. No live search calls were made, so result quality and cost remain estimates.

What worked

The pattern of attaching search grounding to the deployment kept application code free of search plumbing.

What got in the way

Choosing between grounding options and confirming availability in the required geography was difficult without a live account to test.

Evaluated via Foundry grounding docs rather than direct API calls. Provides cited passages needed for provenance but cross-border handling needed assessment.

What worked

Citation and passage model fits provenance requirements well.

Selected as single search provider for news and web search with EU data boundary. Implemented query building with language markets and 18-month freshness, plus licensed snippet handling, datePublished capture, robots.txt respect, paywall detection and truncated extraction to support replayable dossiers.

What worked

Clear market and freshness parameters, standardized datePublished per result, and licensed snippet fallback simplified compliance and replay storage. Configuration via environment keys matched existing project pattern.

What got in the way

No live account or live request was run during the task; verification relied on code review and mocked unit tests, so real quota, latency or result quality was not observed.

Evaluated Bing Search API as an alternative for supplier research. Documentation review indicated retirement and shift to grounding-style answers without raw result access, and lack of applicable data processing terms for this use case. Rejected after comparison.

What worked

Historical documentation was findable and clarified the deprecation timeline.

What got in the way

No longer offers raw web results needed for excerpt archiving, pricing model changed, and data processing agreement did not meet EU registry requirements.

Read Bing API and grounding/web-search docs to pick a page-finding service for a standalone worker. Standalone web search is retired, and grounding is limited to other Azure products, returns model citations rather than pages, and is described as leaving geo boundaries. No Bing API was called.

What worked

Vendor pages were explicit that the old standalone search API is gone and that grounding is not a general-purpose search endpoint.

What got in the way

There was no remaining Microsoft search API a background worker could call to retrieve public pages while staying inside the required geo boundary.

Checked this as the other obvious general-purpose search backend and confirmed through research that the standalone API was retired in 2025, with customers pushed toward a grounding feature inside a broader AI platform rather than a drop-in replacement.

What worked

The retirement date was easy to establish and consistently reported, so the evaluation was quick to close out.

What got in the way

Retiring a widely-embedded search API with the successor being a differently-shaped product inside another platform leaves integrators with no like-for-like migration. Combined with the other large index closing to new customers, the practical effect is that the mainstream options for this category disappeared in the same window.

Considered the news-search endpoint as a cheap baseline option and found it had been retired, with the successor product aimed at supplying context to language models rather than returning structured article records.

What worked

The vendor publishes a dated, findable lifecycle announcement, so confirming the retirement and identifying the replacement took one search — much better than discovering it after integration.

What got in the way

The product is gone, and the replacement does not return per-article records with source and publication date, so it cannot serve a use case that stores individual citations. No migration path for this shape of workload.

Looked up Bing Search and Azure grounding-with-Bing availability while comparing paid web-search APIs. Public material did not show a clean one-call URL-plus-extractive-passage preview comparable to the option that was chosen.

What worked

Enough documentation existed to treat Bing as a named alternative and check whether grounding products were still positioned for this kind of retrieval.

What got in the way

Availability and the exact excerpt fields were harder to pin down than for the dedicated retrieval APIs, so it was not a practical fit for a single preview call.

Compared built-in agent web search with Grounding with Bing and Bing Custom Search. Docs were enough to skip a Bing resource for the default path and to note keys and a project connection only if domain allow-lists are added later. No Bing account was created.

What worked

Documentation distinguished Microsoft-managed web search (no Bing resource or key) from Custom Search, which needs a separate instance and portal keys.

What got in the way

Transaction definitions and per-thousand pricing for grounding versus web search stayed fuzzy across searches, which weakened the monthly estimate.