Bing’s API retirement deadline has passed: check your SEO reports
Bing set August 31 for SOAP and POX retirement. Check integration protocols, JSON parsing and data freshness with our downloadable reporting audit sheet.
Bing’s announced SOAP and POX retirement deadline has passed. If a scheduled SEO report is blank or stale, check its connection and parser before telling a client that search traffic has fallen.
What Bing announced
Microsoft’s Bing Webmaster API documentation, updated August 7, sets August 31, 2026 as the retirement date for the legacy protocols. Its migration notice says those endpoints will no longer serve requests after that date and directs integrations to JSON/HTTP.
This is a documented infrastructure change, not evidence of an organic ranking update. We verified the public documentation on September 5; we did not run authenticated calls or independently measure the shutdown. The checks below are an audit procedure, not a report of an outage affecting our accounts.
Identify the integration, not just the dashboard
Bing identifies /api.svc/pox/ and /api.svc/soap as legacy routes, with /api.svc/json/ the supported route. It says API keys, quotas, permissions and method functionality remain unchanged. That does not make the response format interchangeable.
Start with the job that supplies the report: its connector, operation, owner and last successful run. Inspect configuration or ask the supplier which protocol its current version uses. A dashboard can keep displaying cached numbers even when its upstream job fails. Conversely, a recent job timestamp can accompany old source data.
Save both timestamps: when the job ran and the latest date represented by its returned data. Keep the endpoint path but strip credentials and query-string secrets from the audit record. If the protocol is unknown, assign an owner to confirm it rather than marking the job unaffected.
Check more than the URL
The migration guide describes JSON bodies instead of XML for POST requests, successful responses wrapped in a d property, Microsoft-style date values, and error objects without that success wrapper. An old XML parser cannot simply consume the new response.
Use a read operation first and inspect a redacted response. Then exercise the integration’s parsing locally before touching submission jobs. These are our recommended acceptance checks:
| Check | Evidence to save | Do not accept |
|---|---|---|
| Response handling | Expected fields and row count after parsing | An HTTP success code alone |
| Date conversion | One raw date beside its decoded date and timezone | A plausible-looking date without a comparison |
| Failure handling | A local error fixture produces a visible failure state | Errors silently converted into zero traffic |
| Report continuity | Comparable property, period and metric in a manual export | Comparisons with different date ranges |
A small, explicit fixture is more useful than testing every dashboard at once. Keep one known success response, one empty response and one error response, with secrets removed. Check that the software distinguishes them. Do not manufacture errors by repeatedly sending bad authenticated requests.
Treat missing data as missing data
For a synthetic example, imagine a job runs on September 5 but its newest row is August 28. That observation establishes a freshness problem; it does not establish zero clicks after August 28. Label the affected reporting interval unavailable until a comparable export or repaired job resolves it.
Agree on an expected freshness window with the report owner. If a fallback export is necessary, annotate its source and date range so it does not silently overwrite the automated series. Preserve the last known good output for comparison, not as a claim that it is current. Our AI visibility reporting guide covers the broader problem of keeping unlike metrics separate.
Download the integration audit sheet
Download the Bing API integration audit CSV. One row represents one integration and operation. Record the protocol, secret-free endpoint, latest data date, parser checks, comparison evidence, owner and retest decision. The included EXAMPLE-REMOVE row is fictional; delete or replace it before use.
Keep API keys, access tokens, customer identifiers and unredacted payloads out of the sheet. Use a private evidence reference rather than pasting sensitive logs. Mark a job ready only after its output passes the checks—not merely because its configuration contains “json.” For interpreting Bing citation reports separately, see our Bing AI Performance measurement explainer.
When to recheck
Repeat the comparison after the connector changes or a scheduled run misses its freshness window. We will revise this article if Bing changes its migration guidance or we obtain reproducible integration evidence. Until then, the defensible conclusion is a published retirement deadline and a concrete need to verify dependent jobs—not a measured search-traffic loss.
Keep learning
Continue this topic
Next in this topic
Microsoft AI Max defaults: check new campaigns and Google imports
Earlier in this topic
ChatGPT custom audiences: why uploaded rows are not matched users
Tools & Workflows
Ask a question or join the discussion