Bing Webmaster Tools arrête ses API SOAP et POX le 31 août 2026

L’essentiel

• Après le 31 août 2026, l’API Bing Webmaster Tools ne répondra plus en SOAP ni en POX/HTTP.
• Seul le protocole JSON/HTTP, que Microsoft appelle aussi son API REST, reste en service.
• Méthodes, clé d’API, quotas, limites de débit et permissions ne changent pas, selon Microsoft.
• L’avis de retrait ne mentionne pas IndexNow, qui passe par d’autres points d’accès.

Bing Webmaster Tools ne garde qu’un protocole sur trois

Jusqu’ici, l’API de Bing Webmaster Tools acceptait trois protocoles : SOAP, POX/HTTP (du XML brut envoyé en HTTP) et JSON/HTTP. Dans son avis de retrait, Microsoft explique qu’il regroupe tout sur le JSON et abandonne les deux autres dans le cadre d’une modernisation du service. Passé le 31 août 2026, les requêtes adressées aux anciens points d’accès « ne seront plus servies » (traduction). Le document ne parle d’aucun délai de grâce.

L’annonce a été publiée le 31 juillet 2026 en fin d’après-midi (heure de Paris) sur le compte X de l’équipe Bing Webmaster, puis reprise à l’identique sur LinkedIn par Krishna Madhavan, de Microsoft. Le message indique que « ces API héritées seront retirées le 31 août 2026 » (traduction) et demande aux développeurs de préparer leur passage aux API REST/JSON. Search Engine Roundtable l’a relayé le 3 août. Il reste donc quatre semaines.

Qui est concerné : les intégrations qui appellent /pox/ ou /soap/

Microsoft donne un critère simple. Une intégration est touchée si elle appelle une adresse qui commence par https://ssl.bing.com/webmaster/api.svc/pox/ ou https://ssl.bing.com/webmaster/api.svc/soap/. Celles qui passent déjà par https://ssl.bing.com/webmaster/api.svc/json/ n’ont rien à modifier.

Cette API permet d’ajouter des sites, de soumettre des URL par lots et de récupérer des données de la console, comme les statistiques de requêtes, de liens ou d’exploration. Les exemples de l’avis portent d’ailleurs sur GetUserSites, AddSite et SubmitUrlBatch. À vérifier en priorité : les scripts maison de soumission d’URL, les connecteurs des outils SEO tiers, les anciennes extensions de CMS et les applications .NET dont le client a été généré à partir du WSDL du service SOAP.

Même clé et mêmes quotas, mais un format de réponse différent

Sur le fond, Microsoft affirme que toutes les méthodes existent en JSON et se comportent de la même façon. La clé d’API n’a pas à être régénérée. Pour une requête GET, les paramètres restent dans l’URL : la migration se limite souvent à remplacer le segment /pox/ ou /soap/ par /json/. Les énumérations restent codées en entiers.

Le reste oblige à reprendre le code. L’avis liste ces différences :

• en-tête Content-Type: application/json; charset=utf-8 sur toutes les requêtes ;
• corps des requêtes POST transformé en objet JSON plat, dont les clés sont les noms des paramètres (pour SubmitUrlBatch, un champ siteUrl et un tableau urlList) ;
• réponses placées dans un objet {"d": ...}, avec une propriété __type purement informative ;
• erreurs renvoyées sous la forme {"ErrorCode": ..., "Message": ...}, sans l’enveloppe d ;
• dates au format Microsoft /Date(ticks)/, là où le XML utilisait l’ISO 8601 ;
• barres obliques échappées dans les chaînes (http:\/\/example.com\/), et plus aucun WSDL.

IndexNow absent de l’avis

Le document de Microsoft ne dit pas un mot d’IndexNow. Ce protocole a ses propres points d’accès (api.indexnow.org, bing.com/indexnow) et s’appuie sur une clé hébergée sur le site, sans passer par ssl.bing.com/webmaster/api.svc. Au vu du critère d’URL fourni par Microsoft, les soumissions IndexNow ne devraient pas être touchées. Microsoft ne l’a cependant pas confirmé noir sur blanc.

Ce que j’en retiens

Sur le papier, la migration est légère : un segment d’URL à changer, un en-tête à corriger. Le risque se loge plutôt dans le traitement des réponses. Un script qui lit du XML, attend une date ISO ou ignore l’enveloppe d peut planter, ou continuer à tourner en avalant des erreurs sans rien soumettre.

Je chercherais dès maintenant les chaînes api.svc/pox et api.svc/soap dans le code et les fichiers de configuration, puis je testerais la version JSON sur un appel simple comme GetUserSites avant de basculer les soumissions par lots. Si vous passez par un outil du marché, demandez à l’éditeur quel point d’accès il utilise. Après le 31 août, gardez un œil sur le rapport de soumission d’URL de Bing Webmaster Tools : un flux qui s’arrête net trahira une intégration oubliée.