Which direction does data move between Oracle NetSuite and BigCommerce?

Orders, customers, and refunds move from BigCommerce into Oracle NetSuite, where orders become sales orders and refunds become credit transactions. Item catalog and inventory levels move the other way, from NetSuite into the BigCommerce store. NetSuite stays the financial system of record, so order totals are mapped to NetSuite accounts and dimensions on the NetSuite side.

How does ml-connector handle BigCommerce webhooks that carry only an ID?

BigCommerce webhook payloads contain just a resource type and ID, signed with HMAC-SHA256 in the X-BC-Signature header. ml-connector verifies that signature against the stored client_secret, then immediately calls the BigCommerce REST API to fetch the full order or customer before mapping it into NetSuite. The BigCommerce order ID is stored as the NetSuite externalId so a duplicate delivery upserts instead of creating a second record.

What does the NetSuite certificate-based OAuth setup require?

NetSuite uses OAuth 2.0 client credentials with no client secret, so ml-connector signs a JWT with an RSA or EC private key and the customer uploads the matching public certificate in their NetSuite account against an integration role. Tokens last 60 minutes and there is no refresh token, so ml-connector re-runs the signed flow when a call returns 401. The customer also supplies their account ID, since NetSuite uses account-specific URLs rather than a shared host.

Oracle NetSuiteBigCommerce

Oracle NetSuite and BigCommerce integration

Oracle NetSuite runs finance, inventory, and order management. BigCommerce runs the online store. Connecting the two means orders placed in BigCommerce land in NetSuite as sales orders without re-keying, customers stay aligned across both systems, and the item catalog and stock levels in NetSuite feed the storefront. Refunds issued in BigCommerce post back into NetSuite as credit transactions so revenue and returns stay reconciled. ml-connector handles the very different APIs on each side and moves the data on a schedule you control, with webhooks triggering order sync as soon as a sale closes.

How Oracle NetSuite works

Oracle NetSuite exposes customers, sales orders, invoices, inventory items, GL accounts, and accounting dimensions through SuiteTalk REST Web Services on an account-specific URL, with SuiteQL available for bulk and JOIN reads. Authentication is OAuth 2.0 client credentials (M2M): there is no client secret, so the connector signs a JWT with an RSA or EC private key whose public certificate the customer uploads, and tokens last 60 minutes. NetSuite can push create and edit events through native Event Subscriptions, but those carry no HMAC signature, so source IP allowlisting and a shared secret are used instead. REST writes are record by record and use externalId for idempotent upsert.

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 carries a static X-Auth-Token store API key, generated once with its client_id and client_secret in the store control panel. BigCommerce pushes order, customer, and product events by webhook signed with HMAC-SHA256 over the raw body keyed by the client_secret, but each payload is a stub carrying only a resource type and ID, so the full record must be fetched from the REST API. BigCommerce has no GL accounts, vendors, or purchase orders.

What moves between them

Orders, customers, and refunds move from BigCommerce into Oracle NetSuite. A new BigCommerce order becomes a NetSuite sales order matched to a NetSuite customer, a new or updated shopper becomes a NetSuite customer, and a BigCommerce refund posts into NetSuite as a credit transaction. In the other direction, NetSuite inventory items and stock levels flow into the BigCommerce catalog so product data and availability on the storefront reflect the ERP. Order and customer events are driven by BigCommerce webhooks for near-real-time sync, while NetSuite catalog and inventory reads run on a schedule you set. NetSuite stays the financial system of record, so order totals map to NetSuite accounts and dimensions on the NetSuite side.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For BigCommerce it sends the X-Auth-Token header on every call and verifies each inbound webhook by recomputing the HMAC-SHA256 of the raw body with the stored client_secret and comparing it to the X-BC-Signature header, returning 401 on a mismatch. Because the webhook payload is only a type and ID, it immediately calls GET on the v2 order to fetch the full record before mapping it. For NetSuite it signs a JWT with the customer's private key to obtain a 60-minute OAuth token and re-runs the flow when a call returns 401, since there is no refresh token. Orders are written to NetSuite record by record, with the BigCommerce order ID stored as the NetSuite externalId so a retried delivery upserts rather than duplicates. BigCommerce returns HTTP 429 with rate headers and NetSuite returns 429 with Retry-After, so both sides back off and retry with jitter. BigCommerce webhooks auto-deactivate after about 48 hours of failures or 90 days of inactivity, so a periodic health check re-registers them. If the merchant runs NetSuite OneWorld, a subsidiary is required on each sales order, so subsidiary and dimension mappings are set first. 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 with roughly 150 employees sells direct to shoppers through a BigCommerce store and runs Oracle NetSuite for inventory, fulfillment, and accounting. Before the integration, a clerk exported the day's orders from BigCommerce and re-keyed them into NetSuite as sales orders, paused the storefront whenever stock counts drifted out of sync, and reconciled refunds by hand at month end. With Oracle NetSuite and BigCommerce connected, each order flows into NetSuite within moments of checkout as a sales order tied to the right customer, NetSuite stock levels publish back to the catalog so the store shows real availability, and refunds post as credit transactions automatically. The manual order entry is gone and the books match the store.

What you can do

Create NetSuite sales orders from new BigCommerce orders as soon as a webhook fires, deduplicated by externalId.
Keep customers aligned by turning new and updated BigCommerce shoppers into NetSuite customer records.
Post BigCommerce refunds into Oracle NetSuite as credit transactions so returns and revenue stay reconciled.
Publish NetSuite inventory items and stock levels into the BigCommerce catalog so the storefront reflects the ERP.
Bridge the BigCommerce X-Auth-Token key and NetSuite certificate-signed OAuth, with retries and a full audit trail on every record.

Questions

Which direction does data move between Oracle NetSuite and BigCommerce?: Orders, customers, and refunds move from BigCommerce into Oracle NetSuite, where orders become sales orders and refunds become credit transactions. Item catalog and inventory levels move the other way, from NetSuite into the BigCommerce store. NetSuite stays the financial system of record, so order totals are mapped to NetSuite accounts and dimensions on the NetSuite side.
How does ml-connector handle BigCommerce webhooks that carry only an ID?: BigCommerce webhook payloads contain just a resource type and ID, signed with HMAC-SHA256 in the X-BC-Signature header. ml-connector verifies that signature against the stored client_secret, then immediately calls the BigCommerce REST API to fetch the full order or customer before mapping it into NetSuite. The BigCommerce order ID is stored as the NetSuite externalId so a duplicate delivery upserts instead of creating a second record.
What does the NetSuite certificate-based OAuth setup require?: NetSuite uses OAuth 2.0 client credentials with no client secret, so ml-connector signs a JWT with an RSA or EC private key and the customer uploads the matching public certificate in their NetSuite account against an integration role. Tokens last 60 minutes and there is no refresh token, so ml-connector re-runs the signed flow when a call returns 401. The customer also supplies their account ID, since NetSuite uses account-specific URLs rather than a shared host.

Connect Oracle NetSuite and BigCommerce

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

Get started