Acumatica and BigCommerce integration

What moves between them

The primary flow runs from BigCommerce into Acumatica. As orders are placed and paid, ml-connector reads the order, its transactions, and any refunds and creates the matching sales order or AR invoice in Acumatica, creating or updating the customer first so each document links to a valid account. The reverse flow runs from Acumatica to BigCommerce: stock item price, cost, and inventory level changes update the corresponding BigCommerce catalog products and variants by SKU. Order capture is event-driven on BigCommerce webhooks with a scheduled poll as a catch-up, and catalog pushes run on the schedule you set.

How ml-connector handles it

ml-connector stores both credential sets encrypted, sends the BigCommerce X-Auth-Token on every store call, and runs the Acumatica OAuth flow against the customer's instance, refreshing the bearer token when a call returns 401. It pins the exact Acumatica endpoint version per customer so the version-locked URL resolves, and wraps every field value as {"value": ...} the way the Contract-Based REST API requires. Because BigCommerce webhook payloads are stubs, each order or product event triggers a fetch of the full record before it maps into Acumatica, and SKUs are matched to Acumatica InventoryID so catalog and orders land on the right items. BigCommerce refunds are processed one at a time per order since the API rejects concurrent refunds, and both sides return HTTP 429 under load, so ml-connector backs off with jitter and reads the BigCommerce rate-limit reset header. Webhooks auto-deactivate after about 48 hours of failures or 90 days idle, so a health check re-registers them, and the scheduled poll on LastModifiedDateTime backfills anything a missed push dropped. 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 distributor with roughly 80 staff sells through a BigCommerce store and runs Acumatica Cloud ERP for inventory, AR, and finance. Before the integration, a clerk exported each day's web orders and re-typed them into Acumatica as sales orders, mistyped SKUs and customer details caused picking errors, and the online catalog showed stock the warehouse had already sold. With Acumatica and BigCommerce connected, paid orders post into Acumatica within minutes as sales orders and AR invoices against matched customers, and Acumatica inventory levels push back to the catalog so the storefront stops overselling. The manual entry step is gone and the two systems stay reconciled through the day.

What you can do

• •Create Acumatica sales orders and AR invoices from paid BigCommerce orders, with the customer matched or created first.
• •Capture BigCommerce order transactions and refunds and post them against the right Acumatica documents.
• •Push Acumatica stock item price, cost, and inventory updates to BigCommerce catalog products and variants by SKU.
• •Bridge the BigCommerce static X-Auth-Token and Acumatica OAuth, pinning the exact version-locked endpoint URL.
• •Capture orders on BigCommerce webhooks with a scheduled LastModifiedDateTime poll as catch-up, plus retries and a full audit trail.

Questions

Which direction does data move between Acumatica and BigCommerce?

Orders, payments, refunds, and shoppers move from BigCommerce into Acumatica as sales orders, AR invoices, and customers. Product price, cost, and inventory move the other way, from Acumatica out to the BigCommerce catalog. ml-connector matches customers and SKUs on each pass so every document and catalog item lands on the correct record.

How does the integration deal with Acumatica's version-locked endpoint and field wrapping?

ml-connector accepts the customer's instance URL and exact endpoint version, such as 24.200.001, and pins it on every call so the version-locked path resolves instead of returning 404. It also wraps each field value as a {"value": ...} object, which the Contract-Based REST API requires; flat key-value pairs would be rejected with a 400. Both are handled automatically from the stored configuration.

Does the integration rely on BigCommerce webhooks, and what if one is missed?

Yes. BigCommerce pushes HMAC-signed webhooks for order, customer, and product events, which ml-connector verifies and then uses to fetch the full record, since the payload itself is only a stub. Because webhooks can auto-deactivate after failures or inactivity, a health check re-registers them and a scheduled poll on LastModifiedDateTime backfills anything a missed push dropped.