Which direction does data move between QAD and BigCommerce?

The main flow is BigCommerce into QAD. Orders, payment transactions, refunds, and customers move from BigCommerce into QAD finance, while item and price data can flow the other way to keep the BigCommerce catalog aligned with the QAD item master. Order transactions are system-generated in BigCommerce, so ml-connector posts the financial result into QAD rather than writing journals back to the store.

Does BigCommerce send real-time updates, or does ml-connector poll?

BigCommerce supports push webhooks for order and product events, so ml-connector can react to a sale as it happens. Each webhook payload carries only the resource type and ID, so ml-connector verifies the HMAC-SHA256 signature and then calls the orders endpoint to pull the full record before posting to QAD. QAD cloud has no webhook system, so QAD reads run on a schedule you control.

How are BigCommerce orders mapped into QAD when BigCommerce has no GL accounts?

BigCommerce has no chart of accounts, vendors, or purchase orders, so the GL structure lives entirely in QAD. ml-connector maps order fields such as subtotal, tax, shipping, and refunded amount to the matching QAD GL accounts during setup, and customers and items are matched by email and SKU so each posting references records that already exist in QAD.

QADBigCommerce

QAD and BigCommerce integration

QAD runs manufacturing and finance. BigCommerce runs the online storefront. Connecting the two moves web orders, payments, and refunds out of the store and into QAD finance, so the general ledger reflects e-commerce sales without re-keying. New shoppers in BigCommerce become QAD customers, and item and price changes in QAD can be pushed back to the BigCommerce catalog so the store stays current. ml-connector handles the very different APIs on each side and runs on a schedule you control.

How QAD works

QAD Adaptive ERP exposes customers, items, GL accounts, cost centers, supplier invoices, goods receipts, and AP payments through REST business document APIs, documented in Swagger inside each customer instance. The cloud product authenticates with a JWT session or OAuth2 bearer token against a tenant-specific URL, so there is no shared hostname. Older on-premise sites run QAD Enterprise Edition with the QXtend SOAP framework instead. QAD has no public webhook system for cloud connectors, so its records are read by polling on a schedule.

How BigCommerce works

BigCommerce exposes orders, order transactions, refunds, customers, and catalog products through its REST Management API, with v2 used for order create and read and v3 used for transactions, refunds, customers, and catalog. Every request authenticates with a static access token sent in the X-Auth-Token header from a store-level API account, scoped per store hash. BigCommerce has no GL accounts, vendors, or purchase orders, so order and refund totals map to GL entries on the QAD side. BigCommerce also pushes webhooks for order and product events, but each payload carries only the resource type and ID, so the full record is fetched by a follow-up API call.

What moves between them

The main flow runs from BigCommerce into QAD. ml-connector reads new and updated orders, their payment transactions, and refunds, then posts the sales revenue, tax, shipping, and cash into QAD against the matching GL accounts. Customer records flow the same direction so first-time shoppers become QAD customers. Catalog data can flow the other way, with QAD item and price changes pushed into the BigCommerce product catalog so the store reflects the item master. Order transactions and refunds are read-only or processed in BigCommerce, so ml-connector posts the financial result into QAD rather than writing journals back to the store.

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, scoped to the store hash, with no Bearer prefix. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base URL, and validates entity paths against that instance. BigCommerce order and product webhooks are registered with a verified HMAC-SHA256 signature over the raw body keyed with the client secret, and because each payload is only a type and ID stub, ml-connector immediately calls the orders endpoint to pull the full record before posting to QAD. QAD cloud is pull-only, so QAD reads run on a schedule you set. Customers are matched by email and items by SKU so each order line and journal references a record that already exists in QAD. BigCommerce rate limits return HTTP 429 with a reset header, so ml-connector backs off and retries, processes refunds one at a time per order as the API requires, and re-registers webhooks that BigCommerce auto-deactivates after a failure window. 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 manufacturer builds and ships its own products and sells direct to consumers through a BigCommerce store alongside its wholesale channel, running QAD Adaptive ERP for production, inventory, and finance. Before the integration, a clerk exported web orders from BigCommerce each day and keyed the order totals, tax, and shipping into QAD by hand, while refunds and payment fees were reconciled separately at month-end. With QAD and BigCommerce connected, each order and its payment transactions post into QAD automatically as they happen, refunds reduce the right accounts, and new shoppers land in the QAD customer master. The daily re-keying disappears and the e-commerce ledger is reconciled as orders arrive.

What you can do

Post BigCommerce orders, payment transactions, and refunds into QAD against the correct revenue, tax, shipping, and cash accounts.
Turn first-time BigCommerce shoppers into QAD customers, matched by email to avoid duplicates.
Push QAD item and price changes into the BigCommerce catalog so the storefront reflects the item master.
Authenticate BigCommerce with its store-level X-Auth-Token access token and QAD with its tenant-specific login.
Listen for BigCommerce order webhooks, fetch the full record from each stub, and poll QAD on a schedule with retries and a full audit trail.

Questions

Which direction does data move between QAD and BigCommerce?: The main flow is BigCommerce into QAD. Orders, payment transactions, refunds, and customers move from BigCommerce into QAD finance, while item and price data can flow the other way to keep the BigCommerce catalog aligned with the QAD item master. Order transactions are system-generated in BigCommerce, so ml-connector posts the financial result into QAD rather than writing journals back to the store.
Does BigCommerce send real-time updates, or does ml-connector poll?: BigCommerce supports push webhooks for order and product events, so ml-connector can react to a sale as it happens. Each webhook payload carries only the resource type and ID, so ml-connector verifies the HMAC-SHA256 signature and then calls the orders endpoint to pull the full record before posting to QAD. QAD cloud has no webhook system, so QAD reads run on a schedule you control.
How are BigCommerce orders mapped into QAD when BigCommerce has no GL accounts?: BigCommerce has no chart of accounts, vendors, or purchase orders, so the GL structure lives entirely in QAD. ml-connector maps order fields such as subtotal, tax, shipping, and refunded amount to the matching QAD GL accounts during setup, and customers and items are matched by email and SKU so each posting references records that already exist in QAD.

Connect QAD and BigCommerce

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started