Microsoft Dynamics GP and BigCommerce integration

What moves between them

The main flow runs from BigCommerce into Microsoft Dynamics GP. Each paid order becomes a receivables invoice in GP, the buyer becomes or updates a GP customer, and refunds post as the matching credit, every line mapped to GP customers, items, and GL accounts. Catalog products and inventory move the other direction so stock levels and item records in the storefront reflect what GP holds. Order and refund webhooks trigger the sync as sales happen, and a scheduled poll on modified date backfills anything a webhook missed, since GP itself cannot push.

How ml-connector handles it

ml-connector stores both credential sets encrypted and sends the BigCommerce access token in the X-Auth-Token header on every request, while authenticating to Microsoft Dynamics GP over Windows Negotiate or NTLM with the domain account, presenting the GP base URL, tenant, and SQL database name per customer. Because GP is on-premises, the customer must expose their SBA or SOAP endpoint through the firewall with a valid certificate, or run a local agent the connector relays through. BigCommerce webhooks arrive signed with HMAC-SHA256, so each one is verified against the client secret before processing, and because the payload is only a record type and ID, ml-connector immediately calls the REST API to fetch the full order or refund. GP customers and items are matched first, so every receivables invoice line references a customer and item that already exists, and SBA write bodies are wrapped in the required Payload key. Writes only succeed against unposted GP transactions and an open fiscal period, so a sale for a closed period is held rather than forced. BigCommerce returns HTTP 429 when its rate limit is hit, so ml-connector reads the reset header and backs off, and GP polling is kept to a few parallel calls so the customer's SQL Server is not overloaded. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods company sells through a BigCommerce storefront and runs Microsoft Dynamics GP on a server in its own building for accounting and inventory. Before the integration, a clerk exported web orders each morning and typed the totals into GP as receivables invoices, then reconciled refunds and stock counts by hand, which left the ledger a day behind and the online stock levels often wrong. With the two systems connected, each paid order posts into GP as it happens, refunds follow as credits, and inventory updates flow back to the store. The morning re-keying job is gone and month-end close starts with online sales already in the ledger.

What you can do

• •Post BigCommerce orders into Microsoft Dynamics GP as receivables invoices against the right customers and GL accounts.
• •Create or update GP customer records from BigCommerce buyers so sales land on the correct account.
• •Push GP inventory items and stock levels out to the BigCommerce catalog so the storefront reflects real availability.
• •Record BigCommerce refunds as the matching credits in GP, processed sequentially per order as the API requires.
• •Verify signed BigCommerce order webhooks, then poll GP on a schedule with retries and a full audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics GP and BigCommerce?

The main flow is BigCommerce into Microsoft Dynamics GP. Orders, payment transactions, refunds, and customers move into GP as receivables invoices, customer records, and credits. Inventory items and stock levels move the other way, from GP out to the BigCommerce catalog, so the storefront shows what is actually in stock.

How does the integration reach an on-premises Dynamics GP server from the cloud?

Microsoft Dynamics GP has no cloud endpoint and authenticates only with a Windows domain account, so the customer must expose their Service Based Architecture or Web Services endpoint through their firewall with a valid certificate, or run a local agent the connector relays through. ml-connector stores the domain credentials encrypted and authenticates over Windows Negotiate or NTLM on every call. The company name in each request is the GP SQL Server database name, not the display name.

What happens with BigCommerce webhooks and the lack of webhooks in GP?

BigCommerce order and refund webhooks arrive signed with HMAC-SHA256 and carry only a record type and ID, so ml-connector verifies each one against the client secret and then calls the REST API to fetch the full record before posting it. Because Dynamics GP cannot push events, GP is read by polling on modified date on a schedule you set, and a periodic check re-registers BigCommerce webhooks if they are auto-deactivated after a failure window.