Connecting Dynamics 365 Business Central to a Shop

In many companies, Business Central is the leading system for master data, inventory and order processing. The shop, in turn, is the sales channel that must be available around the clock. Without integration, two separate data sets emerge that drift apart in day-to-day operations: the shop displays outdated prices, orders have to be typed into the ERP manually, and stock discrepancies lead to overselling. A McKinsey study shows that automated end-to-end processes significantly reduce the lead time from order to order creation (McKinsey, 2024).

Business Central offers good prerequisites for integration. The platform provides standardized web services that are accessible via the OData protocol and a modern, AL-based API. This means no proprietary connector is needed that breaks with every update. Instead, a middleware communicates with documented REST endpoints that Microsoft versions and maintains over the long term (Microsoft Learn, 2025). This is exactly what makes the integration robust and maintainable -- an aspect that is often underestimated when choosing the integration architecture.

Business Central exposes its data through several interface variants that differ in convenience and flexibility. For a shop integration, two are particularly relevant: the generic OData layer and the curated AL-based API. Both speak REST and return JSON, but differ in structure and in the stability of their contracts.

The OData endpoints are generated from published pages and queries. They are highly flexible because practically any table can be exposed as a web service -- including filters, sorting and $expand for linked records. The downside: the structure depends on the respective page definition and can change when customizations are made. The AL-based API, by contrast, provides a stable schema defined by Microsoft (e.g. items, customers, salesOrders) and is the recommended choice for integrations because the contracts are versioned (Microsoft Learn, 2025). For special cases, you can also define custom API pages in AL that deliver exactly the fields the interface requires.

Authentication is the first stumbling block in many Business Central integrations. Previously, the web services could be accessed via basic authentication with a username and web service access key. Microsoft has phased out this path for the online variant and relies on OAuth2 via Microsoft Entra ID (formerly Azure AD). For server-to-server integrations without an interactive user, the client credentials flow is the right approach (Microsoft Learn, 2025).

The flow in brief: an app registration is created in Microsoft Entra ID and assigned a client secret or certificate. This app is granted the necessary permissions for Business Central and registered in the environment as an Entra application with matching permission sets. The middleware requests a bearer token with the client ID and secret and sends it in the authorization header of every API request. Tokens are short-lived, so the middleware keeps the current token in a cache and renews it in time before it expires.

On the security side: client secrets do not belong in source code but in a protected secret store, and a certificate is preferable to a secret. The granted permissions should follow the principle of least privilege -- the integration usually needs access to items, prices, inventory, customers and orders, but not to the entire tenant setup. This keeps the data flows GDPR-compliant and traceable.

In most scenarios, Business Central is the leading system for item master data and prices, while the shop is the leading system for editorial content such as descriptions, images, SEO texts and category assignments. This data authority must be defined and documented per entity before the project starts, otherwise the two systems overwrite each other. According to a Forrester analysis, many integration projects fail less on technology and more on unclear responsibilities for data fields (Forrester, 2025).

For items, fields such as number, description, base unit of measure, weight, tax code and blocking flag are transferred. Careful handling of variants is important: Business Central uses item variants, while shop systems map variants via property groups. The middleware must translate this structure and create a base item with configurable variants. So that the entire catalog is not read on every run, the synchronization filters on the systemModifiedAt field and fetches only records that have changed since the last run.

Price synchronization is one of the most demanding parts. Business Central uses sales price lists, discount groups and customer-specific conditions that can be differentiated by customer group, quantity, currency and period. This logic must be translated into the shop's pricing model -- typically via customer groups and price rules with tiers. Since customer-specific prices are the norm in B2B, reliable price synchronization is business-critical. You will find more depth on this in our article on webhooks versus polling, which examines when a push mechanism is more sensible than regular polling.

Inventory is the most time-critical figure of the integration. Every inventory movement -- goods receipt, goods issue, transfer, inventory adjustment -- changes availability, and a delayed update quickly leads to overselling. An Aberdeen Group study shows that current inventory data significantly reduces the rate of overselling (Aberdeen Group, 2024). In B2B there is the added factor that customers expect reliable availability information because they align their own planning with it.

Business Central distinguishes between the pure inventory (quantity on hand) and the actual availability, which takes reserved quantities and open orders into account. For the shop, the calculated availability is usually the more relevant figure, not the raw stock level. With multiple warehouse locations, it must also be defined how consolidation works: as the sum of all locations, as the stock of a specific shipping warehouse or region-specific. We also explore this topic with respect to multi-warehouse scenarios together with the relevant department.

A combination of two mechanisms has proven effective: a frequent delta sync of inventory every two to five minutes and -- where available -- an event-driven push from Business Central. Since the OData layer itself does not offer webhooks for arbitrary tables, the push is often implemented via a small AL extension that sends an HTTP call to the middleware on relevant postings. The periodic delta sync remains active as a safety net so that no change is lost.

For orders, the data flow reverses: the shop is the source, Business Central the target. As soon as a customer places an order in the shop, a sales order should be created in Business Central -- complete, correct and promptly. The middleware translates the cart into an order: shop item numbers are mapped to Business Central items, the customer is referenced to a business partner, and payment and shipping terms are assigned.

In B2B, additional requirements come into play: the customer's order reference numbers, cost centers, alternative delivery addresses and multi-level approvals. The AL API offers the salesOrders and salesOrderLines entities for this, with which header and line data can be created in a structured process. It is crucial that the middleware validates every order before transfer -- missing required fields, invalid item numbers or blocked customers are caught before an incomplete document lands in the ERP.

With growing catalogs and rising order volume, performance becomes the critical factor. A merchant with tens of thousands of items and many price lists generates a considerable data volume that the middleware must process efficiently without overloading the Business Central environment. Microsoft applies throttling limits to the APIs and responds to too many concurrent requests with status code 429 (Microsoft Learn, 2025). A robust integration actively respects these limits.

In practice, optimized integrations reach processing rates with these measures that reconcile even large catalogs in a reasonable time (project experience). The initial import remains a special case: it is performed once with an adjusted batch strategy, temporarily reduced shop indexing and within a maintenance window so that the ongoing limits are not exhausted.

From over 50 ERP integration projects (project experience), certain problems recur regularly. Those who know them plan for them from the start instead of repairing them later in live operation. According to IDC, the complexity of integration is one of the main reasons digital projects take longer than planned (IDC, 2024) -- so good preparation pays off directly.

An integration project follows a structured flow. Experience shows that a thorough analysis phase is the most important investment: the more cleanly requirements, data models and data authority are documented, the more smoothly the implementation proceeds. A typical project can be divided into five phases.