Data integration
Ina Rogalev
24. September 2026
Many companies connect Business Central with shops, warehouse solutions, CRM systems, reporting tools or their own applications. These connections have often been running reliably for years – while still relying on technology that Microsoft is now gradually phasing out: interfaces published via the “Web Services” page.
There is no reason for rushed migrations. But there is a clear need to review existing interfaces in good time. The modern alternative is the standard APIs of Business Central or – if the standard is not sufficient – custom-developed API endpoints.
Using the Web Services page in Business Central, objects from the system could previously be made available as interfaces.
Typical use cases were:
The approach was practical, but it had a fundamental disadvantage: a user interface is not a stable programming interface. If a user personalizes a page – for example by adding, removing or rearranging columns – this can affect the published endpoint. This applies especially when the connected application accesses Business Central using the same user account.
Further information on the previous publishing method can be found in the Microsoft documentation: Publish a web service, SOAP web services and OData web services.
Microsoft distinguishes between SOAP and OData. The key point for the inventory is which pages, queries and codeunits are published in your tenant via the “Web Services” page and which external system uses them.
Important: Microsoft has deprecated SOAP web services and recommends implementing integrations in the future using OData V4 or, preferably, API pages and API queries. Therefore, review each endpoint published via “Web Services” based on its object type – page, query or codeunit –, the technology used and its functional purpose.
The authoritative source for the deprecations is the Microsoft documentation on deprecated platform features.
APIs are specifically designed for exchanging data between systems. Unlike a page in the Business Central client, they are clearly defined and versioned. This brings three main advantages:
For key users, one point is particularly important: the familiar page in Business Central is no longer the contract with the connected system; instead, the functionally defined API is.
Business Central already includes a broad range of standard APIs. These should always be the first option to review before building a custom interface.
Standard APIs for operational business processes
The Standard APIs in version 2.0 cover many key business objects, for example customers, vendors, items, sales documents, purchase documents and ledger entries. They are particularly suitable for classic integrations with shops, CRM systems, warehouses or other business applications.
Analytics APIs for reporting
The Analytics APIsare designed for analytics and reporting scenarios. They provide a suitable basis for transferring data to Power BI or other reporting tools without using a screen page as a data source.
Finance APIs for financial reporting
Microsoft provides dedicated Finance APIs for financial and reporting requirements. One example is theAccounting Periodresource. These APIs are intended for financial reporting requirements and should be specifically reviewed for corresponding use cases.
When the standard is not sufficient
Not every individual process can be mapped with a standard API. In that case, a Business Central partner can develop a custom API page or API query as an extension. This keeps the interface clearly separated, documentable and independent of changes to a user interface.
The “Web Services” list shows which endpoints are published. However, it does not show whether or how often they are still used by other systems. This gap is closed by telemetry in Business Central or Azure Application Insights: incoming calls to SOAP, OData and API endpoints are logged there.
The central Microsoft telemetry code for incoming web service calls is RT0008. For each signal, the following information can be evaluated, among other things:
Microsoft provides sample queries in Kusto Query Language (KQL) for this analysis. The full description of the RT0008 signal, the available fields and sample queries can be found in the Microsoft documentation: Analyzeincoming web service requests using telemetry. Microsoft also provides an overview of web service telemetry.
For a reliable decision, telemetry should be reviewed over a sufficiently long period – including month-end closing, seasonal processes and recurring integration runs. This makes it possible to distinguish which published web services are still relevant and which can be replaced or cleaned up without impact.
The first step is not a technical migration, but transparency. Proceed in a structured way:
Inventory interfaces:Review the “Web Services” page in Business Central. For each entry, document object type, object ID, service name, OData or SOAP URL and the functional purpose. Then supplement this list with the actual calls from telemetry.
Assign owners and consumers:Clarify which external system uses the interface, who is responsible there and whether data is only read or also written.
Prioritize affected endpoints: Assess all published SOAP and OData endpoints before the next updates. Take into account object type, business criticality and planned version upgrades.
Select the appropriate API: First review the standard, analytics or finance APIs. If none of them is sufficient, describe the functional requirement for a custom API.
Test and coordinate the migration: A new API address alone is not enough. Together with the provider of the connected system, review data fields, permissions, error scenarios and the results in the business process.
A simple list with “Interface”, “Object type”, “Connected system”, “Functional purpose”, “SOAP/OData”, “Alternative API” and “Responsible person” is a good starting point.
The deprecation does not affect day-to-day work in Business Central, but rather the technical basis of certain integrations. That is precisely why it can easily be overlooked. Anyone who inventories the existing web services now and selects the appropriate APIs can avoid time pressure before an update and at the same time create a more stable foundation for future integrations.
N4 supports you with the inventory – also with the help of telemetry –, the assessment of your interfaces and the migration to future-proof Business Central APIs.
MARKUS WEILAND
head of microsoft dynamics
Other articles that might be interesting for you
