MsAdsSoap · Waitlist
New API features & enhancements REST-only. Existing SOAP integrations keep running.
SOAP API fully deprecated.
Need more time? Complex integrations can request an extended migration plan from Microsoft Advertising support or their account team.
Dates per Microsoft Learn "Migrate to REST API" and the Microsoft Advertising blog (Apr 1, 2026). Microsoft recommends migrating before Oct 1, 2026 to avoid any impact to API access.
New API features go REST-only on Oct 1 — existing SOAP integrations keep running until SOAP is fully deprecated on Jan 31, 2027. Answer 4 quick questions — direct SOAP or an old SDK (and which language), whether you need new REST-only features, whether you've tried REST or msads, and how complex your integration is. Get your timeline risk, SDK upgrade or REST mapping steps, and a regression checklist. Never paste developer tokens, OAuth tokens, client secrets, account IDs, or code.
Independent tool. Not affiliated with or endorsed by Microsoft. · Market-validation page · Free waitlist · No Microsoft Advertising connection
Problem
Per Microsoft Learn and the Microsoft Advertising blog, the API is moving from legacy SOAP to REST in two steps. From Oct 1, 2026, all new API features and enhancements are available only through REST, while existing SOAP integrations keep running during the transition with no immediate impact. On Jan 31, 2027, the SOAP API is fully deprecated. Microsoft recommends migrating before Oct 1, 2026 to avoid any impact to API access, and the window between the two dates spans most advertisers' Q4 peak season. The official guidance is complete, but it is spread across the migrate, Python, PHP, and API reference pages.
| Date | Status | What changes |
|---|---|---|
| 2024 | Available | REST API introduced (Microsoft Advertising blog). |
| Apr 1, 2026 | Announced | Microsoft Advertising blog "Evolving the Microsoft Advertising API platform" announces the move to REST; existing SOAP integrations: no immediate impact. |
| Oct 1, 2026 | New features REST-only | All new Microsoft Advertising API features and enhancements are available only through the REST API. Existing SOAP integrations keep running during the transition. |
| Jan 31, 2027 | SOAP fully deprecated | The SOAP API is scheduled for full deprecation — the hard deadline. |
Microsoft recommends migrating before Oct 1, 2026 to avoid any impact to API access. Need more time? Large or complex integrations can contact Microsoft Advertising support or their account team for an extended migration plan (no length is published). The release notes advise completing significant development work outside your peak season — Oct 1 to Jan 31 spans most advertisers' Q4.
Solution
A Microsoft Advertising SOAP → REST readiness decision layer for ad-automation teams still on SOAP or an old SDK: your integration × language × new-feature needs × progress × complexity → timeline risk + path + mappings + regression checklist. Not a replacement for Microsoft Learn, not an API connector, and not affiliated with Microsoft.
Ad-tech engineers, agency engineers, and in-house growth / marketing and data engineers who still run bidding, reporting, and account automation on the legacy Microsoft Advertising SOAP API — direct SOAP HTTP calls or older Bing Ads SDKs (.NET / Java below 13.0.22, the Python bingads package, PHP microsoft/bingads) — and haven't finished moving to REST / the new msads SDKs.
From Oct 1, 2026 all new API features and enhancements ship only in REST (existing SOAP integrations keep running, no immediate impact); on Jan 31, 2027 the SOAP API is fully deprecated. The path depends on your language — .NET / Java upgrade the SDK, Python / PHP switch to the new msads packages (imports / namespaces, enums, exceptions, and the auth header all change), no-SDK integrations move to REST URLs + JSON — and the docs are spread across the migrate, Python, PHP, and API reference pages.
Tick 4 questions → personalized timeline risk, SDK upgrade path or REST mapping steps, a SOAP → REST code-change map, and a regression checklist. Never asks for developer tokens, OAuth tokens, client secrets, account / customer IDs, or source code; not a Microsoft Advertising connector.
Know whether Oct 1 is only a new-feature gate for you or a real roadmap blocker, which SDK to upgrade or which REST calls to change before Jan 31, and finish sandbox regression before Q4 peak season. No surprise in Feb 2027 when bidding and reporting jobs fail.
| Your current setup | Official path |
|---|---|
| .NET / Java, Bing Ads SDK below 13.0.22 | Upgrade to the latest SDK — 13.0.29 per the Aug 4, 2026 release notes — and verify each service you use. |
Python, any version of the bingads package | Switch to msads (pip install msads) plus the code changes in the change map below. |
PHP, Composer microsoft/bingads | Switch to Composer microsoft/msads plus namespace and class changes. |
| No SDK (direct SOAP calls) | Move to REST API URLs + JSON requests — every method in the API reference has a REST URL and examples. Microsoft encourages adopting an SDK. |
On .NET / Java 13.0.22 or later? The 13.0.22 release mainly moved Customer Management / Billing to REST, so upgrading to the latest SDK and verifying every service you use is the safer path. Microsoft Learn publishes no .NET / Java code-level migration guide, so we don't invent one.
Features
Marketing points from the product hypothesis — for demand validation, not a formal spec promise.
Need new features? They're REST-only from Oct 1. Otherwise your hard cutoff is Jan 31, 2027. Complex? Consider an extended migration plan. Days left for each.
.NET / Java below 13.0.22 → upgrade to the latest SDK; Python bingads → msads; PHP microsoft/bingads → microsoft/msads; no SDK → REST URLs + JSON.
AuthenticationToken → Authorization: Bearer, imports and namespaces, enums, arrays, WebFault / SoapFault → ApiException, REST hosts.
Campaign Management, Bulk, Reporting, Customer Management, Customer Billing, Ad Insight: host, SDK class, and calls to verify for each.
Test in sandbox first, compare report and bulk outputs, verify bid changes, error handling, enums, and token refresh, then switch production with a rollback.
| Item | SOAP / old SDK | REST / msads |
|---|---|---|
| Auth header (no SDK) | AuthenticationToken: {token} | Authorization: Bearer {token} |
| Python dependencies | suds-jurko | urllib3 / pydantic |
| Python model imports | bingads.v13 | openapi_client.models.campaign / customer / bulk / reporting |
| Python arrays | ArrayOf*, response.CampaignIds['long'] | list, response.CampaignIds |
| Python calls | positional arguments / suds factory; suds_options, set_elements_to_none() | _request= keyword argument; build models directly (factory kept as a compatibility layer); suds_options and set_elements_to_none() removed |
| Python enums / flag enums | original casing; space-separated strings | UPPERCASE; bitwise | |
| Python exceptions | WebFault | ApiException (openapi_client.exceptions) |
| PHP runtime | ext-soap | PHP ^7.4 || ^8.0, no ext-soap, guzzle |
| PHP namespace | Microsoft\BingAds\ | Microsoft\MsAds\Rest\ |
| PHP client | ServiceClient | CampaignManagementServiceApi and the other *ServiceApi classes (async methods available) |
| PHP account context | header | AccountId / CustomerId set in AuthorizationData; call refreshAuthorizationData() after a token refresh |
| PHP style / exceptions | SoapVar; SoapFault | camelCase methods, getters / setters, UPPER_SNAKE enums, no SoapVar; ApiException |
| Hosts | SOAP service endpoints | campaign.api. / bulk.api. / reporting.api. / clientcenter.api. / adinsight.api.bingads.microsoft.com (sandbox: *.api.sandbox.bingads.microsoft.com) |
Python msads still imports ServiceClient and authorization from bingads.* — seeing import bingads doesn't mean you're still on the old package; check what's installed. Python BulkServiceManager / ReportingServiceManager interfaces are unchanged. .NET / Java: no code-level map is published — upgrade to the latest SDK and verify per service.
| Service | REST host (production) | PHP msads class |
|---|---|---|
| Campaign Management | campaign.api.bingads.microsoft.com | CampaignManagementServiceApi |
| Bulk | bulk.api.bingads.microsoft.com | BulkServiceApi |
| Reporting | reporting.api.bingads.microsoft.com | ReportingServiceApi |
| Customer Management | clientcenter.api.bingads.microsoft.com | CustomerManagementServiceApi |
| Customer Billing | clientcenter.api.bingads.microsoft.com | CustomerBillingServiceApi |
| Ad Insight | adinsight.api.bingads.microsoft.com | AdInsightServiceApi |
Sandbox: *.api.sandbox.bingads.microsoft.com — run your regression there first. The official client libraries page notes the PHP SDK doesn't include BulkServiceManager / ReportingServiceManager, so you handle download / upload flows yourself.
How it works
Three steps. No Microsoft Advertising connection, no tokens.
Direct SOAP or an old SDK — and which language? Need new features that ship after Oct 1? Tried REST or msads yet? How complex is your integration?
Oct 1 feature gate vs. Jan 31 hard cutoff, personalized — plus the SDK upgrade or REST mapping steps for your stack, each linked to Microsoft Learn.
SOAP-to-REST change map, service coverage list, and a sandbox regression checklist — never paste tokens, secrets, account IDs, or code.
Use cases
If these situations sound familiar, join the waitlist to help us validate.
bingadsChanges bids every hour. Needs the msads migration list (imports, _request=, enums, exceptions) and a sandbox bidding regression — finished before peak season.
Reporting + Bulk schedules. Needs to check whether the SDK is below 13.0.22, upgrade to the latest, and verify report output matches service by service.
Customer Management + Billing. Needs the namespace and *ServiceApi mapping, with AccountId / CustomerId set in AuthorizationData.
Needs the REST hosts, the Authorization: Bearer header, and JSON requests — and a decision on whether to adopt an official SDK.
New features are REST-only, so the related services need to move first — even though the existing SOAP parts keep running.
Many services, many accounts. Needs to judge whether to request an extended migration plan from support or the account team, and what inventory to prepare before asking.
Public signals
Official Microsoft Learn documentation and the official Microsoft Advertising blog only — public signals, not endorsements. No customer quotes, logos, or invented metrics.
FAQ
No. MsAdsSoap is independent and not affiliated with or endorsed by Microsoft. Everything cites official Microsoft docs with links.
Per Microsoft's docs, existing SOAP integrations keep running during the transition. From Oct 1, new features and enhancements ship only in REST. SOAP is fully deprecated on Jan 31, 2027. Microsoft still recommends migrating before Oct 1 to avoid any impact.
Microsoft Learn covers every language across several pages. We filter to your integration type, language, services, and progress, and output timeline risk, path, mappings, and a regression checklist.
Support and your account team handle your account and extension requests; consultants run full migration projects. MsAdsSoap is a lightweight, static self-serve tool, and the waitlist is free during validation.
Microsoft's guidance is to upgrade to the latest SDK if you're below 13.0.22 (latest in the release notes: 13.0.29). The 13.0.22 release mainly moved Customer Management / Billing to REST, so upgrading to the latest and verifying every service you use is the safer path.
Microsoft says customers who need more time (large or complex integrations) can contact Microsoft Advertising support or their account team for an extended migration plan. No length is published, so we don't promise one.
No. Never asked, never held, never stored. We don't connect to your Microsoft Advertising accounts.
No. The MVP is a static questionnaire + path + mappings + checklist + waitlist.
Waitlist invites go out in batches by email. No fake launch date.
MsAdsSoap is an independent tool, not affiliated with or endorsed by Microsoft. Microsoft and Bing are trademarks of the Microsoft group of companies.
Waitlist
Leave your work email for MsAdsSoap early access and launch notes. Email plus optional checkboxes and dropdowns only — there is no free-text field anywhere on this form.
We'll email early-access invites and launch updates in batches (no promised launch date). Check your inbox for a confirmation email if enabled. Unsubscribe anytime.