Bing Retires Two Webmaster API Protocols on 31 August. Here Is the One String to Grep For.
Microsoft retires the Bing Webmaster Tools SOAP and POX APIs on 31 August 2026. If your endpoint contains /soap or /pox/, the fix is a path swap and a parser.
Microsoft is retiring the legacy SOAP and POX protocols of the Bing Webmaster Tools API on 31 August 2026. The JSON over HTTP protocol is unaffected and is where everything moves.
- How to tell in thirty seconds: Search your code for api.svc. An endpoint containing /api.svc/soap or /api.svc/pox/ is affected; one containing /api.svc/json/ is not. Anything referencing api.svc?wsdl is a SOAP client.
- The fix is smaller than the announcement: For POX callers, swap /pox/ for /json/ in the path and parse JSON instead of XML. Method names, parameters and the apikey querystring are identical across protocols.
- Your credentials do not change: Every documented endpoint takes the same ?apikey= parameter, so there is no key to reissue and no new authentication flow to build.
- Error handling is the part that bites: Failures still return HTTP 400, but the body becomes JSON. SOAP clients lose their generated fault type entirely, so any code matching on the old error shape stops catching anything.
- Check what you did not write: Plugins, agency dashboards, inherited cron jobs and rank-tracking integrations are the usual casualties, because nobody remembers they call Bing at all until a submission job goes quiet.
This is a how-requests-are-formatted change, not a what-you-can-do change. It only hurts the people who find out on 1 September.
Submission APIs only matter if the pages you submit are worth indexing. CrawlRaven joins your Search Console data, GA4 and a 200-point crawl into one ranked plan, from $49 at launch. Try CrawlRaven free: 1 site, no credit card →
There is a note sitting at the top of the Bing Webmaster API documentation that most people will never see, because most people have not opened that page since they set the integration up.
Legacy SOAP and POX APIs will be retired on August 31, 2026. Migrate to our REST APIs to avoid service disruption.
Three weeks of notice, for code that in most shops was written once and has not been opened since. Here is what breaks, who it breaks for, and why the fix is smaller than the announcement makes it sound.
What Microsoft is switching off
The Bing Webmaster API has always been reachable over three protocols. Two of them are going away and one is not.
Three Bing Webmaster API protocols, two of them going away
| Protocol | Endpoint | Status | What to do |
|---|---|---|---|
| SOAP | ssl.bing.com/webmaster/api.svc/soap | Retired 31 Aug 2026 | Migrate. The WSDL and generated service reference go with it. |
| POX | ssl.bing.com/webmaster/api.svc/pox/METHOD | Retired 31 Aug 2026 | Migrate. Swap /pox/ for /json/ and parse JSON instead of XML. |
| JSON over HTTP | ssl.bing.com/webmaster/api.svc/json/METHOD | Supported | Nothing to do. This is the destination. |
Endpoint formats from Microsoft Learn: Bing Webmaster Tools API Services.
SOAP is the oldest of the three, wrapping requests in XML envelopes and publishing a WSDL at https://ssl.bing.com/webmaster/api.svc?wsdl. POX is plain XML over HTTP, called at https://ssl.bing.com/webmaster/api.svc/pox/METHOD_NAME.
JSON over HTTP is the survivor, at https://ssl.bing.com/webmaster/api.svc/json/METHOD_NAME. It is not new, it has been documented alongside the others for years, and it is what Microsoft means by "our REST APIs".
Are you affected? Check one string
Search everywhere code runs for api.svc. That single string appears in all three endpoint formats, so it catches every caller in one pass and the path segment after it tells you the verdict.
/api.svc/soaporapi.svc?wsdlmeans a SOAP client. Affected, and the most work to move./api.svc/pox/means a POX caller. Affected, and close to trivial to move./api.svc/json/means you are already on the supported protocol. Nothing to do.
Search wider than the application repository. Scheduled jobs, serverless functions, a reporting script on somebody's laptop and the WordPress plugin directory are all places this call hides.
What does not change, which is nearly everything
This is a change to how requests are formatted. It is not a change to what the API can do, and the distinction is worth stating plainly before anyone plans a sprint around it.
- The same methods. Microsoft documents POX and JSON samples on each individual method reference page, so anything you call today has a documented JSON equivalent.
- The same API key. Every documented endpoint takes the key as a
?apikey=querystring parameter, whatever the protocol. Nothing to reissue. - The same data. Rank and traffic stats, link details, keyword details, crawl stats, plus URL and sitemap submission.
- The same dashboard. Bing Webmaster Tools in the browser is untouched by any of this.
How to migrate
For a POX caller this is a path swap and a parser change. For a SOAP client it is a rewrite of the transport layer, and unfortunately the SOAP setup was always the most elaborate of the three.
Five steps, and only one of them is code
Grep your codebase, scheduled jobs and serverless functions for api.svc. Two hits matter: /soap and /pox/.
POX callers change /api.svc/pox/METHOD to /api.svc/json/METHOD. The method name, the parameters and the apikey querystring are unchanged.
Responses arrive as JSON rather than XML. SOAP clients lose the generated service reference and call the endpoint directly instead.
Failures still return HTTP 400, but the body is JSON. Code that matched on the XML fault shape will silently stop catching errors.
After that date requests to the retired endpoints are no longer served, so an unmigrated job fails rather than degrades.
Your existing API key carries over: every documented endpoint takes the same ?apikey= parameter.
The old SOAP path involved generating a service reference in Visual Studio, editing app.config, and raising the binding's maxBufferSize and maxReceivedMessageSize to at least 524288 so large responses did not blow up. None of that scaffolding survives, which is genuinely good news: what replaces it is an HTTP request and a JSON parse.
The part that breaks quietly: error handling
Failures still return HTTP 400 on the JSON protocol. What changes is the body, and this is where a migration that looked finished starts lying to you.
- POX returned XML. An error body looked like
<root type="object"><ErrorCode type="number">3</ErrorCode><Message>InvalidApiKey</Message></root>. - JSON returns an object. The same failure arrives as
{"ErrorCode":3,"Message":"InvalidApiKey"}. - SOAP raised a typed fault. Code catching
FaultException<ApiFault>has nothing left to catch, because the exception type came from the generated client.
Test one deliberate failure before you call it done. Send a bad API key, confirm your handler still recognises the error, and only then ship.
The callers you forgot you had
The organisations that will get hurt here are not the ones running a deliberate Bing integration. They are the ones who inherited one.
- WordPress plugins. Microsoft documents a Bing URL Submission plugin that calls the API for you. You cannot see which protocol it uses from the outside, so update it and verify submissions afterwards.
- Agency reporting dashboards. Anything pulling Bing rank and traffic stats into a client report, especially a dashboard built years ago by someone who has since left.
- Inherited cron jobs. The nightly URL submission script on a box nobody logs into is the classic case.
- Rank trackers and SEO platforms. Vendor-side, so not your migration, but worth an email if Bing data appears in a report you send a client.
The dangerous failure mode is not the outage. It is that submission jobs fail silently. A cron that returns a 404 into a log nobody reads looks identical to a cron that is working.
So whatever you migrate, add one check that proves it worked: a successful response written somewhere a human sees, or an alert when the nightly run does not report in. Do that and this deadline becomes a non-event.
IndexNow is a different thing and is not affected
Worth separating, because the two get conflated constantly and only one of them has a deadline.
- IndexNow is an open submission protocol with its own endpoint and a key file hosted in your site root. It is not part of the Webmaster API and this retirement does not touch it.
- The Webmaster API is an authenticated, account-scoped API that reads your data as well as submitting URLs. That is the thing changing protocol.
- If you only ever submitted URLs, IndexNow already covers the job and you may not need to migrate anything at all.
Is the Bing API still worth keeping wired up?
Fair question, and the honest answer depends entirely on whether you read the data or only write to it.
If the integration exists purely to push URLs, IndexNow does that with less maintenance. If it feeds crawl stats, link details or keyword data into reporting, migrating is a couple of hours against losing a data source you already built around.
Either way, submission is the smaller half of the problem.
- Submission gets a URL looked at. It does not make a thin, orphaned or accidentally noindexed page worth indexing.
- The URLs you submit should match your sitemap. The free sitemap checker catches the drift between what you publish and what you are asking engines to fetch.
- Indexability is decided on the page, not at the endpoint. Robots rules, canonicals and noindex directives all outrank a submission call.
Key Takeaways
- →What is happening: Microsoft retires the legacy SOAP and POX protocols of the Bing Webmaster Tools API on 31 August 2026. Requests to those endpoints stop being served on that date.
- →Who is affected: Anyone whose endpoint URL contains /api.svc/soap or /api.svc/pox/, or that references the WSDL at api.svc?wsdl. Callers already using /api.svc/json/ have nothing to do.
- →How to check: Search every place code runs for the string api.svc. It appears in all three endpoint formats, and the path segment after it tells you which protocol you are on.
- →What the fix is: POX callers change /pox/ to /json/ and parse JSON instead of XML. Method names, parameters and the apikey querystring are unchanged. SOAP callers drop the generated service reference and call the endpoint directly.
- →What to test: Error handling. Failures still return HTTP 400 but the body becomes JSON, and SOAP clients lose their typed fault entirely. Send a bad API key deliberately and confirm your handler still fires.
- →What is not affected: IndexNow, which is a separate protocol with its own endpoint and key file, and the Bing Webmaster Tools dashboard itself. Your API key does not change either.
Primary sources used in this post
- Microsoft Learn: Bing Webmaster API, carrying the retirement notice
- Microsoft Learn: Bing Webmaster Tools API Services, with the POX and JSON endpoint formats
- Microsoft Learn: Getting Started with Webmaster API, with the SOAP endpoint and the POX and JSON error samples
- Bing Webmaster Tools Help: SOAP and POX API retirement
- Search Engine Roundtable: Bing Webmaster Tools SOAP/POX APIs to be retired on August 31, 2026
Related reading on CrawlRaven
Frequently asked questions
When are the Bing Webmaster Tools SOAP and POX APIs retired?
31 August 2026. The notice on Microsoft Learn reads: "Legacy SOAP and POX APIs will be retired on August 31, 2026. Migrate to our REST APIs to avoid service disruption." After that date, requests to those endpoints are no longer served, so an unmigrated integration fails outright rather than degrading gracefully.
How do I know if my integration uses SOAP or POX?
Look at the endpoint URL. SOAP clients call https://ssl.bing.com/webmaster/api.svc/soap and usually reference the WSDL at https://ssl.bing.com/webmaster/api.svc?wsdl. POX callers use https://ssl.bing.com/webmaster/api.svc/pox/METHOD_NAME. If your URL contains /api.svc/json/ you are already on the supported protocol and have nothing to do. Searching your codebase, scheduled jobs and serverless functions for the string api.svc finds all three at once.
What actually has to change in my code?
For POX callers, very little: change the /pox/ path segment to /json/ and parse a JSON response instead of an XML one. Method names, parameters and the apikey querystring are the same across protocols. SOAP callers have more work, because the generated service reference and its strongly typed client go away, and calls become plain HTTP requests against the JSON endpoint.
Do I need a new Bing Webmaster API key?
No. The API key is an account-level credential passed as the ?apikey= querystring parameter, and every documented endpoint across all three protocols takes it the same way. There is no reissue step, no OAuth migration forced by this change, and no new consent screen for your users.
Does this affect IndexNow or the Bing URL submission plugin?
IndexNow is a separate mechanism with its own endpoint and its own key file in your site root, so it is not part of this retirement. The Bing URL Submission plugin for WordPress is worth checking, because it calls the Webmaster API on your behalf and you cannot tell which protocol it uses from the outside. Update it to its current version well before the deadline and confirm submissions are still landing afterwards.
What happens if I miss the deadline?
Requests to the retired endpoints stop being served, so whatever the integration did stops happening. The failure mode to plan for is silence: a nightly URL submission job or a stats pull that errors into a log nobody reads looks exactly like a job that is working, right up until someone asks why Bing has not seen the new pages.
Is the Bing Webmaster API worth migrating at all?
That depends on what you use it for, and it is a fair question to ask rather than migrating on autopilot. The API exposes rank and traffic stats, link details, keyword details and crawl stats, plus URL and sitemap submission. If you only ever used it to submit URLs, IndexNow covers that need and is unaffected. If you pull crawl or link data into reporting, the migration is a couple of hours and worth doing.
Does this change what data the Bing API returns?
No. This is a change to how requests are formatted and nothing else. The same methods are available over JSON, and Microsoft documents POX and JSON samples on each individual method reference page, so a method you call today has a documented JSON equivalent you can compare against before you cut over.
15+ years of growing SaaS websites through SEO | Author, 200-Point Audit Checklist
Aditi has spent 15+ years helping SaaS companies scale organic traffic through technical SEO and content strategy. She is the author of the CrawlRaven 200-Point Audit checklist used by agencies and in-house teams to systematically improve search performance.