Business Central web services
By Emil Björk · Microsoft business apps consultant, Gothenburg
The classic OData and SOAP web services in Business Central — how they differ from the v2.0 API, and when to use them.
On this page (6)
Business Central exposes three integration surfaces: the modern v2.0 REST API, custom AL API pages, and the older web services — published pages, queries, and codeunits exposed as OData v4 and SOAP endpoints. The v2.0 API is the preferred path for new integrations, but classic web services still solve problems v2.0 doesn't.
Publishing
From the Web Services page in Business Central, an administrator picks a page, query, or codeunit and publishes it under a short name. The system generates an OData URL (e.g. https://api.businesscentral.dynamics.com/.../ODataV4/Company('Cronus')/MyService) and, for codeunits, a SOAP URL. Anyone with the right Entra credentials and BC permissions can call it.
Page web services (OData)
A published page becomes an OData entity set: read with GET, create with POST, update with PATCH, delete with DELETE. Pages enforce the same triggers and validation as the UI, so a posted entry from OData looks the same as one entered manually. Use page web services when you need write access to standard data and the v2.0 API doesn't expose it.
Query web services (OData read-only)
A published AL query becomes a read-only OData feed. Queries are the right answer for read-heavy reporting — joining several tables, aggregating, filtering, and shaping the result on the server. Excel, Power BI, and SQL Server Integration Services connect to query feeds directly.
Codeunit web services (SOAP)
A published codeunit exposes its public procedures as SOAP operations. The right shape for action-oriented integrations — "post this sales order", "release this purchase order", "approve this credit memo" — where you don't want the caller to manipulate the document fields directly but to invoke a curated business operation.
OData vs v2.0 REST. v2.0 is OData under the hood, but with consistent paging, error formats, ETag concurrency, and a documented OpenAPI surface. Classic page web services are looser, often lacking ETags, with platform-specific quirks. New integrations should prefer v2.0 + custom API pages.
Authentication
All SaaS web services authenticate with Entra ID OAuth 2.0. Basic auth is removed.
Common pattern
Reporting and Excel users consume query web services. Internal automation uses v2.0 or custom API pages. Legacy SOAP integrations migrate to v2.0 over time, but in the meantime SOAP remains supported and stable.
Further reading
Related guides
- Business Central CI/CD with AL-GoHow AL-Go for GitHub turns an AL extension repo into a build-test-deploy pipeline — secrets, environments, and continuous delivery.
- The Business Central API and OData servicesHow external systems talk to Business Central — the v2.0 REST API, OData web services, bound actions, and call limits.
- Isolated storage and secrets in ALHow AL extensions store secrets safely — IsolatedStorage scopes, Azure Key Vault integration.
- The AL debugger in Business Central — a deep diveHow the AL debugger works for developing Business Central extensions — VS Code integration, snapshot debugging, attaching to sessions.
- The AL test frameworkWriting automated tests in AL — test codeunits, test runners, TestPage, mocking, test isolation, and CI with AL-Go.
Browse every guide in Business Central or just AL & development.
Was this helpful?
Signals which guides land and which need work. No account, no comment box — corrections go through the contact page.
Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.