The Business Central API and OData services
How external systems talk to Business Central — the v2.0 REST API, OData web services, bound actions, and call limits.
Business Central has a first-class HTTP API that's the canonical way to integrate it with anything outside the product. The API is what powers Power Automate connectors, mobile apps, Power Pages portals, and partner integrations.
The v2.0 REST API. Microsoft maintains an OpenAPI-described REST API at /api/v2.0/companies({id})/... that covers the most-used entities: customers, vendors, items, sales orders, sales invoices, purchase orders, journals, GL accounts, and many more. Each entity supports the standard verbs (GET, POST, PATCH, DELETE) and OData query semantics ($filter, $select, $expand, $top, $skip). Pagination follows the OData convention with @odata.nextLink.
Custom API pages. When the v2.0 API doesn't expose what you need, partners or in-house developers write AL API pages. An API page targets a single table, lives at a customer-defined publisher / group / version path (e.g. /api/contoso/myapp/v1.0/...), and lets you control exposed fields, behaviour, and security.
Bound actions. Beyond reading and writing entities, API pages can expose bound actions — e.g. post a sales order, cancel an invoice, apply a payment. Actions invoke AL code and return a result, which is how you trigger BC's transactional behaviour rather than just writing fields.
OData v4 web services. A second, older surface exposes any page or query as an OData endpoint when published from the Web Services list. OData is read-and-write, less RESTful than v2.0, and useful for ad-hoc Excel pulls or Power BI imports.
Authentication. SaaS APIs authenticate with Microsoft Entra ID OAuth 2.0 — usually via service-to-service flows with an app registration granted Dynamics 365 Business Central application permissions. Basic Auth is deprecated.
Call limits. Each tenant has API throughput limits: requests per minute per user, and an overall throughput allowance. Going over returns HTTP 429 with a Retry-After header. Well-behaved integrations honour the header, batch where possible, and prefer $expand over multiple round trips.
Webhooks. Business Central can push change notifications to a registered subscriber endpoint when records change, avoiding polling. Subscriptions auto-expire and must be renewed.
Best practice. Use v2.0 first, custom API pages second, OData last, basic auth never.
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.
- Business Central web servicesThe classic OData and SOAP web services in Business Central — how they differ from the v2.0 API, and when to use them.
- 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.
- AL events and integration patternsHow AL events let extensions hook into Business Central — business events, integration events, subscriber patterns, and what to avoid.