Sage 100 and BigCommerce integration

What moves between them

Two directions on a schedule you control. Orders and the customers behind them flow from BigCommerce into Sage 100: each web order becomes a Sage 100 sales order with its line items, and the buyer becomes or updates an AR customer. Product data flows the other way, from Sage 100 out to BigCommerce, so item prices and on-hand inventory levels in the catalog match what the ERP holds. Order webhooks trigger the inbound pull as soon as a sale is placed, and a timestamp poll backfills anything a webhook missed. Inventory and price pushes run on their own poll interval against the Sage 100 agent. Order transactions and refunds are read from BigCommerce v3 for reconciliation but are never written back.

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 call, with no Bearer prefix. On the Sage 100 side it calls the customer-hosted local agent over HTTPS using the agent API key, or the SOAP endpoint with the Logon object and company code, and it supports configurable TLS verification because the Sage 100 server certificate is often self-signed. Because BigCommerce webhook payloads are stubs, each order event triggers an immediate GET on the v2 order to fetch the full record before it is mapped to a Sage 100 sales order. Since Sage 100 cannot push events, product and inventory changes are found by polling. BigCommerce returns HTTP 429 when the plan rate limit is hit, so ml-connector reads the reset header and backs off. Neither system offers an idempotency key, so a web order id maps to a stable Sage 100 sales order number and a GET-before-create check prevents duplicates, while the buyer is matched on ARDivisionNo and CustomerNo. Records are mapped by documented convention until live store and ERP credentials confirm field placement.

A real-world example

A mid-sized outdoor gear wholesaler with roughly 60 staff runs Sage 100 on a Windows server in its warehouse for inventory, AR, and accounting, and sells to the public through a BigCommerce store. Before the integration, a clerk printed each day's web orders and re-keyed them into Sage 100 as sales orders, and stock counts on the site drifted from the real warehouse quantity, leading to oversells the team had to refund. After connecting Sage 100 and BigCommerce, every order posts into Sage 100 within minutes as a sales order tied to an AR customer, and the catalog shows the live on-hand quantity and current price from the ERP. The manual entry step is gone and oversells from stale stock counts stop.

What you can do

• •Turn each BigCommerce order into a Sage 100 sales order with its line items, automatically.
• •Create or update the matching AR customer in Sage 100 from the BigCommerce buyer record.
• •Push Sage 100 item prices and on-hand inventory levels out to the BigCommerce catalog.
• •Bridge the BigCommerce X-Auth-Token and the on-premises Sage 100 agent or SOAP login, with configurable TLS for self-signed certificates.
• •Act on BigCommerce order webhooks to fetch full records, and poll Sage 100 timestamps because it cannot push events.

Questions

Which direction does data move between Sage 100 and BigCommerce?

Both ways. Orders and customers move from BigCommerce into Sage 100, where each web order becomes a sales order and the buyer becomes an AR customer. Item prices and inventory levels move from Sage 100 out to the BigCommerce catalog. Order transactions and refunds are read from BigCommerce for reconciliation but are not written back.

Why does Sage 100 need a local agent instead of a direct cloud connection?

Sage 100 is on-premises and has no cloud API. The eBusiness Web Services SOAP surface only covers Sales Orders and Customers, and the Business Object Interface that covers inventory and the full ledger runs only on the Sage 100 server. To reach sales order and inventory data from outside, a lightweight Windows agent on the customer server wraps the Business Object Interface and exposes it over HTTPS for ml-connector to call.

How are duplicate orders prevented when neither system has an idempotency key?

Neither BigCommerce REST writes nor Sage 100 accepts an idempotency key, so ml-connector maps each BigCommerce order id to a stable Sage 100 sales order number and checks whether that order already exists before creating it. Because BigCommerce webhook payloads only carry a type and id, the full order is fetched from the v2 API first, and BullMQ jobId deduplication keeps a repeated webhook from being processed twice.