Microsoft Dynamics 365 Business Central (the ERP a lot of distributors still call NAV or Navision) is one of the friendlier distribution systems to connect to a B2B storefront, because it was rebuilt around a modern API. That is genuinely different from the older ERPs, and it changes what a good integration looks like. But “friendlier” is not “free”: Business Central has its own constraints, and the biggest one surprises teams who assume a cloud API means unlimited real-time calls. This is how a Business Central integration actually works for a mid-market distributor.
This page goes deep on Business Central specifically. For the wider Microsoft picture (including the enterprise Finance and Operations tier) see our Dynamics 365 ecommerce integration hub; Business Central is the mid-market product and the one most distributors on this stack actually run.
First: Business Central online, or NAV on-premises?
The single fact that shapes the integration is which generation you run, because they expose data differently:
- Business Central online (SaaS) is the modern cloud product. It exposes a proper REST API (OData v4) with OAuth 2.0 authentication, which is the right, standards-based way in. This is what most new Business Central customers run and where a clean integration is easiest.
- Business Central on-premises runs the same modern application but self-hosted, with the same API available plus more control over the environment.
- Dynamics NAV (the predecessor) is still in the field in plenty of distribution shops. NAV integrates through SOAP and OData web services rather than the modern REST API and OAuth flow, so a NAV integration is architected differently from a Business Central online one.
So the first scoping question is your generation and version. A Business Central online integration and a legacy NAV integration are different builds, and a partner who has done both will ask before quoting.
The constraint nobody expects: Microsoft throttles the API
Here is the detail that catches teams out. Because Business Central online is a Microsoft-hosted SaaS, Microsoft enforces API rate limits and throttling to protect the shared service. That means an integration cannot simply hammer the Business Central API in real time for every storefront page view, even though the API is modern and capable. Exceed the limits and Microsoft returns throttling responses, and the integration has to back off and retry.
So the durable pattern for Business Central is the same shape as for any serious ERP integration, for a different reason: pricing and inventory sync into a fast local layer that the storefront reads from, refreshed on a schedule that stays comfortably inside Microsoft’s throttling limits, while orders are written back through the API in a managed, retrying queue. The API is modern; the discipline is still required. A partner who has hit Microsoft’s throttling on a real Business Central project designs for it from the start; one who has not learns it in production.
How a Business Central storefront integration is built
- Authenticate with OAuth. Business Central online uses OAuth 2.0 through Microsoft Entra (Azure AD). Setting up the app registration and permissions correctly is the first real task, and getting the permission scopes right avoids a class of intermittent failures later.
- Sync pricing and inventory into a read layer. Customer price groups, price lists, line discounts, and item availability are pulled from Business Central on a schedule tuned to the throttling limits, into a store the site serves from, so the buyer sees their price and accurate availability without every page hitting the API.
- Provision customers and catalog from Business Central. Customers, price groups, and items originate in Business Central and flow to the storefront, keeping the site in sync with where the team already manages the data.
- Write orders back through the API in a queue. Web orders post as sales orders in Business Central with the right customer, dimensions, and lines, through a queue that respects throttling and isolates failures per order.
- Handle dimensions correctly. More on this below, but it is a distinct Business Central design step, not an afterthought.
Business Central specifics that shape the integration
- Dimensions. This is Business Central’s analytical tagging system: every transaction can carry dimensions (department, region, project, salesperson) that finance uses for reporting. A web order that posts without the correct dimensions creates a reconciliation and reporting gap. A correct integration knows which dimensions your setup requires and populates them, which a generic connector often does not.
- Customer price groups and line discounts. Business Central resolves price through customer price groups, price lists, and line and invoice discounts. Reproducing that per logged-in customer is the core pricing task, and it is more layered than a single price list.
- Item variants and units of measure. Business Central handles item variants and multiple units of measure (each, case, pallet). How these surface and price on the storefront is a real modeling decision for a distributor.
- Locations (warehouses). Inventory is tracked by location. Multi-location distributors need location-level availability carried through the sync, not flattened.
- AL extensions. Business Central customizations are built as AL extensions, and many real installations carry custom fields and logic in them. The integration has to account for the fields and behavior those extensions add.
For enterprise customers buying through procurement systems, a Business Central catalog can also be exposed via PunchOut (cXML or OCI), so the storefront doubles as a punchout endpoint.
Is Business Central a good platform to build a storefront on?
For a mid-market distributor or manufacturer, Business Central is one of the better-positioned ERPs for a B2B storefront, precisely because its modern API makes a clean integration achievable, as long as the design respects Microsoft’s throttling. The honest caveats: if you are still on legacy NAV, expect a web-services integration rather than the modern REST flow, and factor the eventual move to Business Central into your thinking; and if your operation is heading toward the enterprise Finance and Operations tier, that is a different integration worth scoping separately. We would rather map that with you before the build than discover it during.
For the storefront platform itself, our Magento B2B development guide and our Shopware work cover the choice; the Business Central integration underneath is built the same way either way.
What a Business Central storefront changes
| What changes | Why | Direction |
|---|---|---|
| Order-entry labor | Orders customers place themselves stop being keyed into Business Central by your team | Down, in proportion to phoned and emailed volume |
| Reporting accuracy | Web orders post with the correct dimensions, so finance keeps clean analytical reporting | Fewer reconciliation gaps |
| Order accuracy | Orders post through the API with validated customers, pricing, and items | Fewer credits and reships |
| Average order value | A buyer browsing the full, correctly priced catalog adds lines a manual order never would | Up, compounding with adoption |
How much each moves depends on how much of your Business Central order volume is routine reorder traffic today, which an honest scoping conversation establishes before modeling a return.
Who builds this
Web Solutions NYC builds B2B commerce for distributors and manufacturers, with the ERP integration that makes it actually work. We have done this since 2007, with senior engineers in US time zones and deep experience across Epicor Prophet 21, Sage, SAP Business One, Microsoft Dynamics 365 Business Central, and Acumatica. We build on both Adobe Commerce (Magento) and Shopware, so the recommendation follows your requirements rather than our inventory. We are a Shopware Platinum Partner and an official Adobe Commerce partner.
Bring your Business Central details, leave with a straight answer
If you are weighing a storefront on Business Central, the facts that decide the project are: Business Central online or legacy NAV and which version, how your pricing is structured (price groups, price lists, line discounts), and how orders reach you today. With those we can tell you what the integration really involves, including how we design around Microsoft’s API throttling and your dimension setup. Book a Scoping Session
What is the best ecommerce platform for Business Central?
The one whose integration respects how Business Central actually behaves: Microsoft API throttling, dimensions, and layered customer pricing. For complex B2B catalogs and pricing, Adobe Commerce (Magento) offers the deepest feature set; Shopware is the modern, lower-overhead alternative Web Solutions NYC also builds on. For simple catalogs, a SaaS platform with a native BC connector can be enough. The platform matters less than whether the integration is designed for throttling and posts orders with correct dimensions.
Frequently asked questions
Business Central online has a modern REST API (OData v4) with OAuth, which makes integration cleaner than with many older ERPs. But because it is a Microsoft-hosted SaaS, Microsoft throttles API calls, so a good integration does not call the API for every storefront page view. The durable pattern syncs pricing and inventory into a fast local read layer on a schedule that stays within the throttling limits, and writes orders back through the API in a managed queue. Near real time, yes; unlimited live calls, no.
Business Central online uses a modern REST API with OAuth 2.0 authentication through Microsoft Entra, which is the standards-based path for a new integration. Dynamics NAV, the predecessor still running in many distribution shops, integrates through SOAP and OData web services instead. The two are architected differently, so the first scoping question for any Microsoft ERP storefront is which generation and version you run.
Dimensions are Business Central’s analytical tagging system: transactions carry dimensions like department, region, or salesperson that finance uses for reporting. If web orders post without the dimensions your setup requires, they create reporting and reconciliation gaps. A correct integration populates the right dimensions on every web order, which is a distinct Business Central design step that generic connectors frequently miss.
Yes. Because Business Central online is a Microsoft-hosted SaaS, Microsoft enforces API rate limits to protect the shared service, and exceeding them returns throttling responses. This is the constraint that most surprises teams, because the API is otherwise modern and capable. The integration has to sync on a schedule that stays within the limits and write back through a queue that backs off and retries, rather than making unlimited live calls. Designing for throttling from the start is the difference between a stable Business Central integration and one that fails intermittently.
A packaged connector can work when your pricing, dimensions, and catalog are standard. Business Central distributors often are not standard: required dimensions, layered price groups and line discounts, item variants and units of measure, and custom fields added through AL extensions are where packaged connectors run short. The honest test is how much custom logic lives in your Business Central setup. We build the integration where a connector cannot cover you, designed around Microsoft’s throttling and your dimension requirements, and we will tell you if a connector honestly would.