Business Central web services
The classic OData and SOAP web services in Business Central — how they differ from the v2.0 API, and when to use them.
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.
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.
- Isolated storage and secrets in ALHow AL extensions store secrets safely — IsolatedStorage scopes, Azure Key Vault integration, and the patterns for managing credentials in Business Central code.
- 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, and the productivity tricks.
- 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.
- AL events and integration patternsHow AL events let extensions hook into Business Central — business events, integration events, subscriber patterns, and what to avoid.