Microsoft Dynamics 365 Business Central and BigCommerce integration

What moves between them

The primary flow runs from BigCommerce into Microsoft Dynamics 365 Business Central. New and updated storefront orders become sales orders or posted sales invoices in Business Central, and the shopper on each order is created or matched as a Business Central customer. Order line SKUs map to Business Central item numbers, and order totals, tax, and shipping map onto the invoice and its GL accounts. A second flow runs from Business Central back to BigCommerce: item unit prices and inventory levels are pushed to the matching catalog products and variants so the store reflects current pricing and stock. BigCommerce has no chart of accounts, so ml-connector never writes GL entries to the store; it maps order amounts to accounts inside Business Central instead.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Business Central side it requests an Entra ID client-credentials token, scoped to the Business Central API, and builds the base URL from the tenant and the stored environment name, since each tenant and environment has its own path. On the BigCommerce side it sends the static X-Auth-Token on every call and keeps the client_secret to verify webhooks. BigCommerce order and inventory webhooks arrive signed with HMAC-SHA256 in the X-BC-Signature header and are verified against the raw body before anything else; because the payload is only a type and ID, the connector then calls GET /v2/orders/{id} to load the full order. SKUs are matched to Business Central item numbers first so every invoice line references an item that already exists, and customers are matched by email before a new one is created. Business Central change subscriptions for items and customers are renewed on a cron before the three-day expiry and answer the validation-token handshake, and because those notifications also omit data, the connector fetches the changed record. Where webhooks are missed or unavailable, an incremental poll uses an OData lastModifiedDateTime filter on the ERP and cursor pagination on BigCommerce. BigCommerce returns HTTP 429 when its 30-second rate window is exhausted and Business Central returns 429 under throttling, so ml-connector backs off with jitter and retries. Refunds are processed sequentially per order because BigCommerce does not allow concurrent refunds on one order. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A growing consumer-goods company with roughly 120 staff sells through a BigCommerce storefront and runs finance and inventory in Microsoft Dynamics 365 Business Central. Before the integration, a clerk exported the day's BigCommerce orders to a spreadsheet and keyed them into Business Central as sales invoices, while a second person updated web prices and stock by hand whenever the catalog changed in the ERP. Orders posted a day late, oversells happened when the store showed stock the warehouse no longer had, and month-end close stalled while sales totals were reconciled against the store. With Microsoft Dynamics 365 Business Central and BigCommerce connected, each order posts as it is placed, item prices and stock flow out to the catalog automatically, and the daily re-keying and stock-fixing work is gone.

What you can do

• •Turn BigCommerce orders into Business Central sales orders or posted sales invoices as they are placed, with no re-keying.
• •Match or create the Business Central customer for each storefront shopper by email.
• •Push Business Central item prices and inventory levels out to the matching BigCommerce products and variants.
• •Verify each BigCommerce webhook by HMAC-SHA256 and fetch the full order before posting, and renew Business Central subscriptions before they expire.
• •Map order SKUs to Business Central item numbers and order totals to GL accounts so revenue lands on the right ledger lines.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and BigCommerce?

Orders and shoppers move from BigCommerce into Business Central, where they become sales invoices and customers. Item prices and inventory levels move the other way, from Business Central out to the BigCommerce catalog. BigCommerce has no chart of accounts, so ml-connector never writes GL entries to the store and maps order amounts to accounts inside Business Central instead.

How are BigCommerce order webhooks handled?

BigCommerce signs each webhook with HMAC-SHA256 using the app client_secret in the X-BC-Signature header, and ml-connector verifies that signature against the raw body before doing anything. The payload is only a resource type and ID, so the connector then calls GET /v2/orders/{id} to load the full order before posting it. Inbound jobs are deduplicated by a stable job id so a redelivered webhook is not processed twice.

Does the integration use webhooks or polling on the Business Central side?

Both. Business Central supports change subscriptions for items and customers, and ml-connector renews them on a schedule before the three-day expiry and answers the validation-token handshake. Because those notifications carry no data and some entities are not webhook-enabled, an incremental poll using an OData filter on lastModifiedDateTime catches anything a subscription misses.