Microsoft Dynamics 365 Business Central
SOAP on standard pages is going away:
what to check before version 29
Business Central 2026 release wave 2 removes the ability to publish Microsoft's own pages as SOAP web services. In our experience the integrations built on those endpoints are rarely the ones anyone is watching — they are bank files, EDI feeds and NAV-era point integrations that have quietly worked for a decade.
What is actually changing
From version 29.0 — the 2026 release wave 2 update — Business Central no longer lets you expose Microsoft's own UI pages as SOAP web services. Microsoft's reasoning is worth understanding, because it explains why this was always going to happen: a UI page is not a contract. Microsoft changes those pages whenever a release calls for it, without treating the change as breaking, because from their side it isn't. From your side, an integration bound to that page breaks anyway.
Be precise about the scope, because a lot of the commentary is not. This is not the removal of SOAP from Business Central. Your own pages, published as SOAP web services from an extension, keep working in version 29. What disappears is the specific ability to point a SOAP endpoint at a page Microsoft ships. SOAP as a whole is separately deprecated and will be removed at some future release, but Microsoft has not named that version.
The timeline, in four versions
This has been signposted since 2024. The last step is the one that breaks things.
Version 24 — announced
Microsoft published the deprecation in the 2024 release wave 1 platform notes, naming version 29.0 as the removal point. Nothing changed in behaviour; this was notice.
Version 26 — off by default
A feature key, 'Disable SOAP web services on Microsoft UI pages', arrived switched on for all users, which blocks publishing Microsoft pages as SOAP. Note the direction: the key must be turned OFF for the old behaviour to keep working. Tenants that never touched it have been blocked since 2025 release wave 1.
Version 29 — removed
The capability goes, and so does the feature key. There is no switch to flip and no supported way to keep an existing endpoint alive. Calls to those endpoints stop resolving.
When version 29 reaches you
Release wave 2 goes to general availability from 1 October, but the actual date your environments update varies by country and region, and by the update window set in your admin centre. Check yours rather than assuming 1 October.
What is not changing
SOAP endpoints on your own extension pages still work. OData and the REST APIs are unaffected. If your integrations already use API pages or queries, this change costs you nothing.
Who this affects
The pattern is consistent: the older the integration, the more likely it is on this list.
- Estates upgraded from NAV or Navision, where SOAP was the normal integration route at the time
- Bank file and payment integrations that read or write through a standard page
- EDI setups exchanging orders, despatch notes and invoices with trading partners
- Warehouse, scanner and shop-floor systems talking to standard item and document pages
- Excel and Power Query reports pointed at SOAP endpoints rather than API pages
- Middleware and iPaaS flows — Logic Apps, BizTalk, third-party brokers — built before API pages existed
- Any integration built by a partner who is no longer involved, which is where the real risk sits
“A UI page isn't an API.”
Why this is harder than it looks
The change itself is simple. Finding out what it touches is not.
Nobody has a list
SOAP endpoints were published one at a time, over years, often by people who have since left or by partners no longer engaged. The Web Services page tells you what is published, not what is still being called, by whom, or whether anything would notice if it stopped.
Failures will be silent and late
An overnight bank file or an EDI despatch feed does not announce itself when it stops. It is discovered days later by a supplier chasing an order or a payment that never arrived — usually by someone outside IT.
The feature key hides your true position
If someone turned the key off in version 26 to unblock an integration, that endpoint is working today and will stop in version 29. The tenants most exposed are precisely the ones where the change appeared to have been handled.
Replacements are not always drop-in
A standard API page rarely exposes exactly the fields a page-based SOAP endpoint returned. Some migrations are a URL change; others need an API page built, or the Microsoft page replicated in an extension, and the calling system adjusted to match.
The window is shorter than the calendar suggests
Testing against a preview sandbox, coordinating changes with banks, EDI partners and external vendors, and getting their release cycles to line up with yours takes longer than the remediation itself.
Not sure which of your integrations are affected?
If your environment sends telemetry to Application Insights, Business Central has been recording the answer since version 26. It takes an afternoon to read.
How to work out your exposure
Most of this you can do yourself, and the first step is the one that matters. We are happy to run it with you if a second pair of eyes helps.
- 1
Read the telemetry Microsoft already collects
From version 26, Business Central emits a dedicated 'Deprecated endpoint called' event — event ID RT0053 — every time something hits an affected endpoint. If your environment sends telemetry to Application Insights, the answer is already sitting there, with the endpoint, the object and the environment. This is the fastest honest picture of your exposure, and far better than reading the Web Services page. One practical warning: Microsoft's own sample query spells the field 'depricationMessage', which returns blanks against the documented 'deprecationMessage'.
- 2
Separate the live from the abandoned
Published is not the same as used. Cross-reference the deprecated-endpoint events against general web service telemetry filtered to the SOAP category to see which endpoints carry real traffic, how often, and from where. Retiring an unused endpoint is free; the list is usually shorter than the published one.
- 3
Pick the right replacement per endpoint
Microsoft gives three routes: move to the built-in REST APIs, which is the recommended option and generally the fastest for standard entities; move to OData V4; or copy the Microsoft page into a per-tenant extension and publish that as a SOAP endpoint, which preserves the existing contract when you cannot change the calling system. That third option is the pragmatic one for bank and EDI integrations owned by someone else.
- 4
Test against a preview sandbox before the update lands
Microsoft makes preview environments available ahead of general availability. Point each remediated integration at one and confirm it works before your production environment updates — not after. Where an external partner has to change something on their side, start that conversation now, since their release cycle is the constraint you do not control.
What you get from doing this properly
Beyond not breaking on the day the update lands.
- A documented inventory of what actually integrates with Business Central, which most organisations do not have
- Dead endpoints retired instead of migrated, reducing both work and attack surface
- Faster integrations, since API pages are built for this and standard pages carry UI overhead on every call
- Advance notice for banks, EDI partners and vendors rather than an incident conversation
- A clean position for the next deprecation, because SOAP overall is going the same way
- Confidence that the October update is routine rather than something to brace for
“The endpoints that break will be the ones nobody remembers publishing.”
Common questions
What we are asked most often about this change.
Want a second pair of eyes on your integration landscape?
We work with Business Central estates across Denmark, Sweden and the wider Nordics, including plenty that carry NAV history. If you would like help reading your telemetry or planning the migrations, we are glad to look.