Integrating Microsoft Dynamics 365 Business Central With Magento and Hyva

Integrating Microsoft Dynamics 365 Business Central with Magento means deciding which system owns each object, then syncing customers, catalog, price lists, inventory, orders, invoices, shipments, and returns through the Business Central REST API. Business Central owns pricing, stock, and credit. Magento owns the storefront. Rate limits force a read-layer and queued-write architecture, not live calls.

We are Bemeir, a Brooklyn ecommerce development agency and the USA’s first and leading official Hyva Gold Partner, with more than sixteen years building B2B stores on Magento and Adobe Commerce for manufacturers and distributors. This guide is written from shipped integrations. It is specific to Business Central, not a generic ERP piece, because the connector market, the API surface, and the pricing model all behave differently here than they do with SAP, NetSuite, or Dynamics 365 Finance and Operations.

Why Business Central is a distinct integration problem

Most articles on this topic say the same three things: sync orders, sync inventory, sync customers, and buy a connector to do it. That is the commodity answer, and it is not wrong so much as incomplete. It skips every decision that determines whether the go-live holds up.

Business Central online is a modern REST platform. It exposes standard API pages under /api/v2.0/ over OData v4, secured with OAuth 2.0 through Microsoft Entra ID, and it supports webhooks. That is cleaner than the SOAP and ODBC era of NAV. But the same platform enforces hard operational limits that shape the entire design. Business Central is also multi-company and dimension-driven, which changes how orders and customers must be modeled. And its pricing engine, built from customer price groups, price lists, and line and invoice discounts, is where B2B integrations succeed or fail.

Get those three facts wrong and no connector saves you. Get them right and the connector choice becomes a budget question, not an architecture risk.

Decide the system of record before choosing a tool

The most expensive mistakes are made in the first planning meeting. Before anyone compares Celigo against a custom build, the team agrees on which system is authoritative for each object.

The clean division for a B2B Adobe Commerce store is this. Business Central owns pricing, on-hand inventory, credit limits, credit-hold status, item master data, and order, invoice, and shipment status once an order is posted. Magento owns the storefront, the cart, requisition lists, negotiable quotes in progress, and the checkout experience before an order is submitted. Customer identity is shared, and one side must win: Business Central holds the accounting customer and company hierarchy, Magento holds the login and web profile, linked by a stable external ID.

When both systems think they own pricing or stock, you get bidirectional conflicts that loop and drift you cannot reconcile. Writing the ownership map object by object is the most valuable hour in the project. Our Adobe Commerce B2B and ERP integration architecture guide covers that mapping exercise in more depth.

Which objects sync, in which direction, and how often

Here is the object map we start every Business Central build from. Treat frequency as a default to tune against your order volume and the rate limits described below.

Two details separate this from a generic ERP map. First, every sales order pushed into Business Central needs the right dimensions attached, which are the analytical tags such as department, region, salesperson, and project that finance reports on. An order without correct dimensions posts fine and then creates a reporting gap that surfaces at month end. Design the dimension mapping up front. Second, in a multi-company Business Central tenant, each web store maps to one company, and the API path is company-scoped, so a multi-store Magento build has to route each order to the correct company ID.

B2B pricing is the hard part

Consumer catalogs have one price. B2B does not. Business Central builds a customer’s net price from several layers: the price list assigned to that customer or customer price group, plus line discounts, plus invoice discounts, plus any campaign pricing. Reproducing that on the storefront is the core task, and it is why generic connectors often stall on B2B accounts.

You have two workable patterns. The first is to precompute and sync customer-specific prices as Magento catalog price rules or shared catalog entries, refreshed on a schedule. This keeps the storefront fast because prices are already local, and it fits Magento B2B shared catalogs well. The tradeoff is freshness: a price changed in Business Central at 10 a.m. is not on the store until the next sync. The second pattern is to fetch the contract price at the moment it matters, on the product and cart pages, through a lightweight call to a middleware cache rather than to Business Central directly. That is fresher but demands the caching layer described next so you never call the ERP on a page render.

For most distributors we precompute prices nightly and layer a real-time check at add-to-cart and checkout for the accounts where price accuracy is contractual. Do not invent a pricing model the customer does not have. Read the actual price list structure in their tenant first, because two Business Central deployments rarely price the same way.

Rendering live pricing, stock, and credit on Hyva without breaking cache

This is where a fast Magento theme and an ERP have to coexist. A Hyva storefront is fast because pages are served from full page cache. Customer-specific price, live stock, and remaining credit are all per-customer, so they cannot be baked into a cached page without leaking one buyer’s terms to another.

Magento solves this with private content, also called customer section data. The cached HTML is public and shared. Per-customer values load separately over Ajax and are stored client side, so the fast cached shell stays intact. Adobe’s own guidance is to keep public content in the full page cache and pull anything customer-specific through this private mechanism. Hyva streamlines that model: section data loads once, broadcasts through the private-content-loaded JavaScript event, and Alpine components read from it. The mechanics are documented in Hyva’s working with sectionData reference.

The pattern that holds up in production is this. Render the product page from cache with a neutral or list price. On load, a private-content section supplies the logged-in customer’s contract price, their real-time available stock for the relevant location, and their credit status, and the component swaps those values in. The section endpoint reads from your middleware cache, never from Business Central live, so page speed does not depend on ERP response time. One caution specific to Hyva: sections are combined into a single data object and are not invalidated individually, so plan invalidation deliberately after cart actions rather than assuming a single field refreshes on its own. We go deeper on this in our write-up on B2B commerce on Hyva.

Connector, iPaaS, or custom middleware

There are prebuilt Magento-to-Business Central connectors on the market, iPaaS platforms such as Boomi, Celigo, Alumio, and Codeless Platforms, and fully custom middleware. None is correct for every project. Match the tool to the complexity of the pricing and the volume of orders.

One point the marketplace listings skip: standard Business Central API pages cannot be extended with extra fields in place. If the standard entity is missing something you need, the supported route is to copy the AL code and publish a custom API page, which is an AL development task on the ERP side regardless of which connector sits in the middle. Microsoft’s Business Central API v2.0 reference documents the standard surface and the connect-app model. Budget for a small amount of AL work on any non-trivial B2B build.

Respect the rate limits or the integration will throttle itself

This is the constraint the commodity guides omit, and it drives the architecture. Business Central online enforces documented operation limits on the OData and API layer. Requests over the ceiling return HTTP 429, and slow ones can queue until they time out. The verified figures at the time of writing include a rate ceiling on OData v4 requests, a per-request page-size cap of 20,000 entities, a maximum of 100 operations per $batch request, and a limit of 200 webhook subscriptions per environment. Microsoft has also moved several of these from per-environment to per-user limits, which means spreading load across service principals raises throughput.

The practical consequences are direct. You cannot call Business Central on every storefront page view. You sync catalog, pricing, and stock into a local read layer on a schedule that stays inside the rate ceiling, and the storefront reads only from that layer. Order writes go through a queue with retry and backoff so a burst of checkouts does not trip 429. You page large pulls and use $batch to combine writes. Build all of this to be idempotent: every order carries a stable external ID, so a retried write updates rather than duplicates, and a webhook delivered twice is a no-op. Log every request and response with correlation IDs, and put failed messages on a dead-letter queue with alerting rather than silently dropping them. This is the difference between an integration that runs unattended and one that pages someone every week.

Real-time where it counts, batch everywhere else

Not everything needs to be instant, and pretending it does wastes your rate budget. Use event-driven webhooks or short polling for the things a buyer notices during a session: inventory availability, order acknowledgment, shipment and tracking updates. Use batch windows for the heavy, less time-sensitive loads: full catalog refreshes, price list rebuilds, and posted invoice history. Credit status sits in between; refresh it on a short interval and re-check it at checkout so an over-limit order is caught before it posts. The goal is that the buyer sees fresh data where a stale number would cost a sale or an oversell, and the ERP is left alone everywhere else.

Phased rollout

A big-bang cutover on an ERP integration is how go-lives slip. We sequence it.

Phase one is read-only catalog and inventory: items and stock flow from Business Central to Magento, nothing writes back, and you prove the read layer and the sync cadence. Phase two adds customers and B2B pricing, including the private-content rendering on Hyva, validated against a set of real accounts. Phase three turns on order submission from Magento to Business Central with the queue, idempotency, and dimension mapping, run in parallel with the existing order process before you rely on it. Phase four closes the loop with invoices, shipments, and returns, and then you decommission the manual steps. Each phase is independently useful, so value lands early and risk stays contained.

Where Bemeir fits

We build these integrations end to end, from the ownership map through the AL work, the middleware, and the Hyva storefront rendering. Business Central is common among mid-market distributors and manufacturers, which is exactly the B2B profile we build for. Our team has spent years on Magento and Adobe Commerce B2B, and the same practice supports Shopify and Shopify Plus, BigCommerce, and Shopware when a different platform is the right call. You can read more about Bemeir and our technology partners. We build it, you sell it.

Frequently asked questions

Can Dynamics 365 Business Central integrate with Magento in real time?

Partly. Order submission, inventory changes, and shipment updates can be near real time through queued API calls and webhooks. Catalog, pricing, and full stock reloads should run on scheduled batches, because Business Central enforces API rate limits that make live calls on every page view impractical. The right design mixes both.

Should Business Central or Magento be the system of record for pricing?

Business Central. It owns the price lists, customer price groups, and line and invoice discounts that produce a B2B customer’s net price. Magento renders those prices but should not be authoritative for them. Sync computed prices to the store and, where accuracy is contractual, verify at add-to-cart and checkout.

How do you show customer-specific pricing on a Hyva store without slowing it down?

Serve the page from full page cache with a neutral price, then load the customer’s contract price, live stock, and credit through Magento private content, which Hyva exposes as section data. The section endpoint reads from a middleware cache rather than calling Business Central directly, so page speed never depends on ERP response time.

Do I need a prebuilt connector or custom middleware?

It depends on pricing complexity and order volume. Prebuilt connectors fit standard catalogs and get you started fast. Complex B2B pricing, high volume, or strict caching and idempotency requirements usually justify custom middleware or an iPaaS platform. Most non-trivial builds also need a small amount of AL work to expose custom fields.

What are the main risks in a Business Central to Magento project?

Wrong system-of-record decisions, missing dimensions on synced orders, ignoring API rate limits, and non-idempotent writes that duplicate orders on retry. Each is avoidable with an ownership map, a dimension plan, a queued and rate-aware sync layer, and stable external IDs on every record.