Magento and Business Central integration: the options and the pitfalls.

When the shop and the finance system do not talk, someone re-keys orders, stock is wrong by the afternoon, and prices drift between the website and the price list. Connecting Magento or Adobe Commerce to Microsoft Dynamics 365 Business Central fixes that, if it is built to cope with what actually happens: busy days, half-shipped orders, refunds, a price change to ten thousand items at once and the occasional outage on either side. This article sets out the options and the pitfalls we see most.

What are the options for connecting Magento to Business Central?

Three: a connector extension, a middleware platform, or an integration built on the two APIs. A connector extension installs into Magento, Business Central or both and maps the common records out of the box; it is the quickest start and fits stores whose processes match its assumptions. A middleware or integration platform sits between the two systems, with its own mapping tools, queues and monitoring; it suits businesses connecting several systems, not just these two. A built integration uses Business Central’s API and Magento’s REST endpoints directly, with a queue and mapping layer designed around your data, on a store that should itself be on a supported Magento release; it costs more to start and fits stores whose pricing, products or posting rules are their own. Microsoft’s documentation describes a Shopify Connector built into Business Central; for Magento the connection always comes from one of these three, which is one reason some merchants weigh a move from Magento to Shopify.

Approach	Best when	Watch for	Who supports it
Connector extension	Standard flows, standard Business Central setup	Assumptions that do not match your posting rules; upgrades of either side breaking it	The extension vendor
Middleware platform	Several systems to connect, a team to run it	A third system to licence, learn and monitor	The platform and whoever configured it
Built integration	Custom pricing, products or processes	Needs documenting and an owner for its whole life	The agency that built it

Which records move, and in which direction?

Orders go out of Magento; stock, prices, invoices and shipments come back; customers can go either way. That is the usual shape, shown in the figure. A web order becomes a sales order in Business Central as it is placed. Available stock per item, and per location if you use locations, returns to Magento so the store stops selling what the warehouse no longer has. Prices come from Business Central price lists, including customer and group pricing. Posted invoices, credit notes and despatch details return against the Magento order so customers see them in their account. Customers are the awkward one: if accounts are created on both sides, every field needs an agreed owner, or each system will keep overwriting the other.

What limits does Business Central put on an integration?

Rate limits, page sizes, timeouts and webhook rules, and an integration that ignores them works in testing and fails on Black Friday. For Business Central online, Microsoft publishes operational limits. OData requests are limited per user to 6,000 within a five-minute sliding window; beyond that Business Central answers HTTP 429, Too Many Requests. A single OData request can return at most 20,000 entities, a $batch request can carry at most 100 operations, and a request is cancelled after eight minutes. An environment can hold at most 200 webhook subscriptions. Microsoft’s own advice is that an integration sending everything through one user will reach the per-user limits quickly.

Limit	Value	What happens when exceeded
OData requests per user	6,000 per 5-minute sliding window	HTTP 429, Too Many Requests
Entities per OData request	20,000	HTTP 413, Request Entity Too Large
Operations per $batch request	100	Not stated; split larger batches
OData operation timeout	8 minutes	HTTP 408 and the session is cancelled
Webhook subscriptions per environment	200	Not stated; share subscriptions

How quickly can Business Central tell Magento something changed?

Within about half a minute, by design, and in bulk when a lot changes at once. Business Central’s webhooks do not fire the instant a record changes. Microsoft says the system waits 30 seconds after the first change to an entity so that several quick edits produce one notification; if more than 1,000 records change in that window, it sends a single collection notification and the subscriber must fetch the changed records itself. If the subscriber cannot be reached and answers with a timeout, 429 or server error, Business Central retries over the next 36 hours; any other error deletes the subscription. On the Magento side, Adobe’s asynchronous and bulk REST endpoints accept large updates and write them to a message queue for consumers to process, which on self-hosted stores needs RabbitMQ and running consumers.

Where do Magento and Business Central integrations go wrong?

In the mapping, far more often than in the code. The API calls are the easy part. The decisions that cause months of small errors are these:

• Items and variants. A configurable product in Magento and an item with variants in Business Central are different shapes. Decide which Magento SKU maps to which item and variant code before anything is built.
• VAT and rounding. Line-level and order-level rounding differ between systems; a penny difference on every tenth order adds up to a reconciliation problem.
• Discounts, shipping and gift cards. Each needs a place in the sales order, usually a G/L account or charge item, agreed with your finance team.
• Edits after export. Orders changed or cancelled in Magento after they reach Business Central need a rule, or the two quietly diverge.
• Part shipments and refunds. Credit notes and partial deliveries have to flow back against the right order lines.
• Posting groups, dimensions and number series. A customised Business Central decides how orders must arrive; read it as carefully as the store.
• One user for everything. Under per-user limits, a single integration account becomes the bottleneck on the busiest day.

What should you test before go-live?

Every awkward case your business actually has, on a Business Central sandbox and a staging store, with real data. A test that only places a single full-price order with standard delivery proves very little. Before switching off the old process, run at least these:

• An order with a discount code, a free-delivery threshold and a gift card, and check every line posts to the agreed account.
• An order that ships in two parts, and one that is partly refunded, with the credit note flowing back.
• A price change to thousands of items at once, timed against the webhook delay and the per-user request limit.
• A stock change at one location when the store sells from several.
• A new trade customer created in Business Central and a new account created on the store, to prove field ownership both ways.
• Business Central or the store deliberately unavailable for an hour, to prove the queue holds and retries without duplicating orders.
• A webhook subscription left to expire, to prove someone is alerted.

Then run the integration alongside the existing process for long enough to cover a busy week, and compare totals daily before trusting it alone.

How should you choose?

Start from your data and processes, then pick the approach that fits them, not the other way round. Write down every flow: the records, the fields, the direction, which system owns each field and how often it must move. If a connector covers that list with configuration alone, it is probably the right answer. If you are connecting more than two systems and have someone to run a platform, middleware earns its place. If the list is full of exceptions, trade pricing, bundles, custom posting, a built integration will cost less over its life than bending a connector. Whichever you choose, insist on three things: a queue so nothing is lost, an alert for every failure, and a period running alongside the old process before you switch it off.