Microsoft Dynamics 365 F&O and BigCommerce integration

What moves between them

The main flow runs from BigCommerce into Microsoft Dynamics 365 F&O. ml-connector reads BigCommerce orders, the order transactions captured against them, and refunds, then posts them into D365 F&O as sales and receivables mapped to the matching D365 customers, items, and accounts. Customer records flow the same direction so the D365 CustomersV3 master reflects storefront buyers, and product references are aligned so each order line resolves to a real released product number. GL postings stay in D365, since BigCommerce has no GL resource, so ml-connector never writes ledger entries back to the store.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the BigCommerce side it sends the static access token in the X-Auth-Token header against the store-hash base URL, reading orders from v2 and transactions and refunds from v3. On the Microsoft Dynamics 365 F&O side it requests an Entra ID client-credentials token for the environment .default scope and refreshes it before the roughly one-hour expiry, accepts the full tenant environment URL per customer since D365 publishes no shared base URL, and scopes writes to the right legal entity with the dataAreaId key. Customers and products are mapped first, so every order line references a D365 item and a customer that already exist, and financial dimensions are written as the formatted display string D365 expects. A BigCommerce webhook payload is only a stub, so on store/order/created ml-connector verifies the X-BC-Signature, then calls back to GET the full order before posting; a scheduled poll backfills anything a webhook missed, since hooks auto-deactivate after about 48 hours of failures. D365 has no idempotency key on OData writes and uses natural keys, so ml-connector dedupes on the BigCommerce order id and a BullMQ jobId before posting, which avoids a duplicate-key violation on a re-read order. Both sides return HTTP 429, so requests back off on the BigCommerce window reset and the D365 Retry-After header.

A real-world example

A mid-sized outdoor gear brand with roughly 150 employees sells direct to consumers through a BigCommerce storefront and runs Microsoft Dynamics 365 F&O for inventory, fulfillment, and finance. Before the integration, a clerk exported web orders to a spreadsheet and keyed each one into D365 by hand, which meant orders sat for hours, SKUs were sometimes typed wrong, and the storefront sales never matched the receivables in the ledger. With Microsoft Dynamics 365 F&O and BigCommerce connected, each order and its captured transactions flow into D365 within the polling window, allocated to the correct customer and item, and refunds post as credit notes. Orders reach the warehouse sooner, the keying errors are gone, and the sales accounts reconcile without a month-end scramble.

What you can do

• •Post BigCommerce orders and captured transactions into Microsoft Dynamics 365 F&O as sales and receivables.
• •Map BigCommerce SKUs to D365 released product numbers so every order line lands on a real item.
• •Keep the D365 CustomersV3 master aligned with BigCommerce storefront buyers.
• •Authenticate BigCommerce with its X-Auth-Token and D365 with an Entra ID OAuth token per environment.
• •Verify BigCommerce HMAC webhooks, dedupe on order id and jobId, and poll on a schedule with retries and a full audit trail.

Questions

Which direction does data move between Microsoft Dynamics 365 F&O and BigCommerce?

The main flow is BigCommerce into Microsoft Dynamics 365 F&O. Orders, the transactions captured against them, refunds, and customer records move from BigCommerce into D365, while product references are aligned so order lines resolve to real released products. BigCommerce has no GL account resource, so the general ledger stays in D365 and ml-connector never writes ledger entries back to the store.

Does BigCommerce push orders, or does ml-connector poll for them?

Both are supported. BigCommerce pushes signed webhooks such as store/order/created, which ml-connector verifies with the HMAC-SHA256 X-BC-Signature and then uses as a trigger to fetch the full order, since the payload is only a stub. Because BigCommerce hooks auto-deactivate after about 48 hours of failed deliveries, a scheduled poll runs as well so nothing is missed.

How does the integration handle D365's tenant URL and OAuth tokens?

ml-connector accepts the full Microsoft Dynamics 365 F&O environment URL per customer, since D365 publishes no shared base address, and scopes writes to the correct legal entity with the dataAreaId key. It requests an Entra ID client-credentials token for the environment .default scope and refreshes it before the roughly one-hour expiry, so calls do not fail on an expired token.