Bing SOAP and POX APIs retire 31 August 2026: the JSON migration checklist

Summary. Microsoft will stop serving the Bing Webmaster Tools SOAP and POX/HTTP endpoints on 31 August 2026, leaving JSON/HTTP as the only supported protocol. The notice published on Bing's help site is blunt: after that date, "requests to these endpoints will no longer be served." There is no throttling phase and no announced grace period. What survives the cutover is most of your integration — the same API key, the same daily ceiling of 10,000 submitted URLs per site, the same batch limit of 500 URLs per call, and the same method names. What breaks is the URL path, the XML request and response bodies, and any WCF service reference generated from the WSDL at https://ssl.bing.com/webmaster/api.svc?wsdl. It follows a year of closures on the same platform: the Bing Search and Bing Custom Search APIs went dark on 11 August 2025, and PPC Land reported in June 2025 that the recommended replacement, Grounding with Bing Search, was listed at $35 per 1,000 transactions against the retiring S3 tier's $6 per 1,000. The Webmaster Tools API, by contrast, stays free. The only cost here is engineering time, and you have until 31 August 2026 to spend it.

Most teams will find this is a two-hour change. The teams that will not are the ones running a C# client built through Visual Studio's "Add Service Reference" wizard, because that code is generated against the SOAP contract and has to be replaced rather than repointed.

What Microsoft actually announced

The retirement was flagged in early August 2026 on Bing's official channels and picked up by Search Engine Roundtable on 3 August 2026. Krishna Madhavan, Principal Product Manager at Microsoft AI, Bing, posted the reminder:

"These legacy APIs will be retired on August 31, 2026. Please review the migration guidance and plan your move to our REST/JSON APIs."

The notice on the Bing Webmaster Tools help site carries the operative wording: "The SOAP and POX/HTTP APIs will be retired on August 31, 2026. After this date, requests to these endpoints will no longer be served. Migrate to the JSON/HTTP (REST) API before August 31, 2026 to avoid service interruption."

Read "no longer be served" literally. A deprecation that degrades gracefully gives you a warning header, a 299 response, or a sunset window with rising error rates. This one is a switch. If your nightly indexing job still POSTs to /webmaster/api.svc/pox/SubmitUrlBatch on 1 September 2026, it fails, and because most teams wrap URL submission in a fire-and-forget task, it may fail silently for weeks before anyone notices the drop in Bing-discovered pages.

Note the wording: "plan your move", not "your calls will keep working". Microsoft's own guidance elsewhere has already shifted, which matters for step 4 below — for a large share of integrations the right answer is no longer "port the SOAP call to JSON".

What does not change

Microsoft has been unusually specific about the parts of the contract that are stable. From the retirement notice:

• Every API method remains available over JSON/HTTP with identical functionality.

• Your existing API key continues to work. No re-issuance is required.

• Quotas, rate limits and permissions are unchanged.

• The JSON/HTTP endpoints continue to be supported and actively developed.

That last point is the one worth internalising before you scope the work. This is not a platform migration in the sense that the Bing Search API shutdown was, where the replacement had a different data model, a different billing model and lived inside Azure. Here you are changing a path segment and a serialisation format against the same backend, the same account and the same key.

The published quota behaviour is unchanged too. GetUrlSubmissionQuota returns a DailyQuota and MonthlyQuota pair; Bing's own documentation example shows a response of {"DailyQuota": 973, "MonthlyQuota": 10973}. The 10,000-URLs-per-day allowance introduced with the Adaptive URL Submission programme in January 2019 still governs, and SubmitUrlBatch still caps at 500 URLs per request unless your remaining quota is lower.

The endpoint map: before and after

Three protocols, one survivor. The table below is the substitution list to work through.

Two details in that table cause most of the avoidable breakage.

The first is the d envelope. POX and JSON do not return the same shape. A GetUrlSubmissionQuota call over JSON returns {"d": {"__type": "UrlSubmissionQuota:#Microsoft.Bing.Webmaster.Api", "DailyQuota": 973, "MonthlyQuota": 10973}}. Code that reads response["DailyQuota"] will throw a KeyError; it needs response["d"]["DailyQuota"]. Write-style calls such as SubmitUrl and SubmitUrlBatch return {"d": null} on success, which is easy to mistake for a failure if your client treats a null payload as an error.

The second is method-name casing. Bing's cURL guidance on the Webmaster blog uses SubmitUrlBatch, while the JSON request sample on the Microsoft Learn reference page for the same method shows the path as SubmitUrlbatch with a lowercase b. The documentation is inconsistent. Test the exact string your client sends against a low-value URL before you cut over a production job, and log the response body rather than only the status code.

Step 1: find every legacy call in your codebase

Do this before you estimate the work. Legacy Bing calls hide in scheduled jobs, CMS plugins, deployment hooks and one-off scripts far more often than in application code.

            # Endpoint paths, WSDL references and the generated SOAP client, in one pass
grep -rEn "api\.svc/(soap|pox)|api\.svc\?wsdl|ssl\.bing\.com/webmaster" \
  --include='*.{py,js,ts,cs,php,rb,go,java,xml,config,json,yml,yaml,sh}' .

# The C# service-reference tell-tales, which grep for the endpoint alone will miss
grep -rn "WebmasterApiClient\|IWebmasterApi\|BasicHttpBinding_IWebmasterApi" .
          

Then widen the search beyond the repository. Check your CI secrets and environment variables for a Bing API key (its presence tells you a job exists somewhere), your cron and scheduler definitions, any WordPress or Drupal SEO plugin that offers "submit to Bing", and any sitemap-generation step in your deploy pipeline. On a mid-sized publishing stack we would expect three to five call sites, not one.

Step 2: rewrite the calls

The JSON API is plain HTTP. Here is submission, batch submission and a quota check, first as shell commands you can paste to confirm your key works, then as production Python.

            # Single URL
curl -X POST "https://ssl.bing.com/webmaster/api.svc/json/SubmitUrl?apikey=API_KEY" \
  -H "Content-Type: application/json" -H "charset: utf-8" \
  -d '{"siteUrl":"https://www.example.com","url":"https://www.example.com/about"}'
# -> {"d": null}

# Batch (max 500 per call)
curl -X POST "https://ssl.bing.com/webmaster/api.svc/json/SubmitUrlBatch?apikey=API_KEY" \
  -H "Content-Type: application/json" -H "charset: utf-8" \
  -d '{"siteUrl":"https://www.example.com","urlList":["https://www.example.com/about","https://www.example.com/projects"]}'
# -> {"d": null}

# Remaining quota
curl "https://ssl.bing.com/webmaster/api.svc/json/GetUrlSubmissionQuota?siteUrl=https://www.example.com&apikey=API_KEY"
# -> {"d":{"__type":"UrlSubmissionQuota:#Microsoft.Bing.Webmaster.Api","DailyQuota":973,"MonthlyQuota":10973}}
          

Bing's own guidance is explicit that cURL is for prototyping: use "a server-side script or application in your preferred language to handle authentication, batching, or error handling" in production. The Python below does the three things the shell version does not — it respects the batch ceiling, checks quota before spending it, and unwraps the d envelope.

            import json, math, urllib.request, urllib.error

BASE = "https://ssl.bing.com/webmaster/api.svc/json"
BATCH_MAX = 500  # Microsoft's documented per-call ceiling


def _call(method, payload=None, params=None, api_key=""):
    qs = "?apikey=" + api_key
    for k, v in (params or {}).items():
        qs += "&%s=%s" % (k, urllib.parse.quote(str(v), safe=""))
    body = json.dumps(payload).encode() if payload is not None else None
    req = urllib.request.Request(
        "%s/%s%s" % (BASE, method, qs), data=body,
        method="POST" if body else "GET",
        headers={"Content-Type": "application/json; charset=utf-8"},
    )
    try:
        with urllib.request.urlopen(req, timeout=30) as r:
            raw = r.read().decode() or "{}"
    except urllib.error.HTTPError as e:
        # JSON API returns HTTP 400 with {"ErrorCode": n, "Message": "..."}
        detail = e.read().decode(errors="replace")
        raise RuntimeError("Bing %s failed: HTTP %s %s" % (method, e.code, detail))
    return json.loads(raw).get("d")  # unwrap the d envelope


def remaining_daily_quota(site_url, api_key):
    d = _call("GetUrlSubmissionQuota", params={"siteUrl": site_url}, api_key=api_key)
    return int(d["DailyQuota"])


def submit_urls(site_url, urls, api_key):
    budget = remaining_daily_quota(site_url, api_key)
    if budget <= 0:
        return 0
    urls = list(dict.fromkeys(urls))[:budget]  # de-dupe, then clamp to quota
    sent = 0
    for i in range(0, len(urls), BATCH_MAX):
        chunk = urls[i:i + BATCH_MAX]
        _call("SubmitUrlBatch",
              payload={"siteUrl": site_url, "urlList": chunk},
              api_key=api_key)
        sent += len(chunk)
    return sent
          

Two things that code does deliberately. It de-duplicates before clamping, because a batch of 500 containing 200 repeats burns 500 units of a 10,000-unit daily allowance for 300 useful submissions. And it raises on HTTP 400 with the response body attached, because {"ErrorCode":3,"Message":"InvalidApiKey"} tells you exactly what went wrong while a bare HTTPError: 400 does not.

If you are running the .NET client, delete the service reference rather than trying to repoint it. The generated WebmasterApiClient, the contract="WebmasterApi.IWebmasterApi" endpoint entry, and the maxBufferSize/maxReceivedMessageSize tuning that Microsoft's SOAP guide told you to raise to 524288 all become dead weight. HttpClient plus System.Text.Json replaces the lot in well under a hundred lines.

Step 3: fix authentication, and decide which of the two modes you need

The Bing Webmaster API supports two authentication models, and they use different hosts. Getting this wrong produces a confusing 400 rather than a clear 401.

If you are on the API key path, the migration touches nothing about authentication. If you are on OAuth, note that the host in Microsoft's own SubmitUrl example is www.bing.com, not ssl.bing.com — copying the API-key URL and bolting a bearer header onto it is a common failure.

One security note worth acting on while you are in this code anyway: the API key sits in the query string, which means it lands in access logs, proxy logs and any error-tracking payload that captures request URLs. Scrub it in your logging middleware. Teams that treat this as an ordinary secret and only inject it at request time tend not to notice that it is being written to disk on every call.

Step 4: decide whether to migrate the call at all

This is the part a straight port misses. Microsoft added a note to its own cURL guide in November 2025 stating that it "now recommends using IndexNow as the primary method for real-time URL submission to Bing and participating search engines," describing the Adaptive URL Submission API as remaining "supported for advanced use cases and custom platform integrations."

That is a meaningful reframing from the vendor that owns both. If the only thing your integration does is push new and updated URLs at Bing, IndexNow is the smaller surface: it is a flat POST with a key file on your own domain, it needs no Bing account credential in your deployment pipeline, and the same ping reaches other participating engines. If your integration also reads data — rank and traffic statistics, crawl issues, keyword data, verified site lists — the Webmaster API is the only route and you are migrating it regardless.

The honest read: most publishing teams should move URL submission to IndexNow and keep a slimmed JSON client only for the reporting calls they actually consume. A migration deadline is the cheapest moment to delete code you no longer need. If your Bing integration exists only because someone wired it up in 2019 and nobody has read its output since, the correct migration is deletion.

Step 5: a cutover plan that fits the remaining window

From 5 August 2026 you have 26 days. That is comfortable for a change of this size, and it is not comfortable if the work sits behind a release train with a two-week cadence.

That last row is the check most teams skip. The failure mode after a silent cutover is not an alert — it is a quota that stops being consumed, which looks like nothing at all on a dashboard nobody opens. An alert on "daily quota unchanged for 48 hours" catches it in two days rather than two months.

India-specific considerations

Bing's share of search in India is small next to Google's, which is exactly why these integrations rot: nobody is watching the output closely enough to notice a 400. Three points for Indian teams specifically.

For product and agency teams in Gurugram, Bengaluru and Hyderabad running submission jobs on behalf of overseas clients, the OAuth path is the correct one, not a shared API key pasted into a config file. A client-held key that a departing engineer still has is a genuine problem; a revocable delegated grant is not. The Webmaster.read scope is enough for reporting-only integrations, and requesting Webmaster.manage when you only read is a needless expansion of access.

On data handling, the API key and any OAuth refresh token are credentials that let a third party act on a client's web property, so treat them with the same care as any production secret. The traffic and query reports you pull back can be joined to user-level analytics, and wherever that happens your existing posture under the Digital Personal Data Protection Act 2023 applies to the store you land them in. Design the pipeline so the raw pull lands in the same governed store as the rest of your search data rather than in an engineer's laptop notebook.

On sequencing, teams supporting both Indian and international properties should migrate the lowest-traffic property first and watch quota drawdown for a full week before touching the flagship. The Bing account is per-site verified, so a mistake on a secondary property costs you nothing beyond the submissions you skipped that day.

The wider pattern: Microsoft is consolidating Bing's API surface

This retirement is not an isolated tidy-up. Microsoft retired the Bing Search and Bing Custom Search APIs on 11 August 2025, announced only three months earlier on 12 May 2025, and the Azure notice made the scope clear: "Any existing instances of Bing Search APIs will be decommissioned completely, and the product will no longer be available for usage or new customer signup." The replacement, Grounding with Bing Search inside Azure AI Foundry, does not return raw results at all — as Microsoft's documentation states, "Developers and end users don't have access to raw content returned from Grounding with Bing Search."

The cost shift there was steep. PPC Land's June 2025 analysis put Grounding with Bing Search at $35 per 1,000 transactions against retiring tiers of $6, $15 and $25 per 1,000, a 40% to 483% increase depending on which tier you were on.

Against that backdrop, the Webmaster Tools change is the mild one: same key, same quotas, same price of zero, three months' notice, and a JSON endpoint that has existed alongside SOAP and POX since the API's early days. The direction of travel is still worth reading. Microsoft is narrowing Bing's programmatic surface to a small number of actively developed endpoints and pushing everything else toward either IndexNow or Azure. Integrations built on the oldest available protocol are the ones that keep getting caught. The real cost is usually the discovery, not the code.

FAQ

How eCorpIT can help

We run API integration modernization work for teams carrying exactly this kind of legacy surface — an integration nobody owns, built against a protocol the vendor is closing. Our senior engineering teams do the discovery pass across your repositories and pipelines, decide per call site whether to port, replace or delete, and ship the cutover behind a flag with parallel-run verification so nothing goes quiet unnoticed. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified, and we design integrations aligned with DPDP requirements. If a 31 August deadline is sitting in your backlog without an owner, talk to us.

Related reading: our web platform developer guide covers the wider 2026 browser and API baseline, the Next.js 16 migration guide walks a comparable framework cutover, and the Search Console AI performance report guide covers the Google-side reporting most teams pair with Bing data.

References

1. Bing Webmaster Tools SOAP/POX APIs To Be Retired On August 31, 2026 — Search Engine Roundtable, 3 August 2026

1. Bing Webmaster Tools API Services (supported protocols and URL formats) — Microsoft Learn

1. Getting Started with Webmaster API (SOAP endpoint, WSDL, POX and JSON error samples) — Microsoft Learn

1. Accessing Bing Webmaster APIs using OAuth 2.0 — Microsoft Learn

1. IWebmasterApi.SubmitUrlBatch method (500-URL batch limit, JSON request and response samples) — Microsoft Learn

1. IWebmasterApi.GetUrlSubmissionQuota method — Microsoft Learn

1. Accessing Bing Webmaster Tools API using cURL (with the November 2025 IndexNow note) — Bing Webmaster Blog

1. bingbot Series: submitting up to 10,000 URLs per day to Bing — Bing Webmaster Blog, January 2019

1. Easy set-up guide for Bing's Adaptive URL submission API — Bing Webmaster Blog, May 2019

1. Microsoft ends Bing Search APIs on August 11, alternative costs 40-483% more — PPC Land, 9 June 2025

1. Bing Search APIs Retiring August 11, 2025 — Search Engine Roundtable, 14 May 2025

1. Grounding with Bing Search in Foundry Agent Service — Microsoft Learn

1. IndexNow — Bing

1. Bing Webmaster API overview — Microsoft Learn

1. Microsoft expands Bing Webmaster Tools data capabilities to 24 months (Krishna Madhavan's role at Microsoft AI, Bing) — PPC Land

Last updated: 5 August 2026.