How to Sync BigCommerce Orders to NetSuite

Automatically push BigCommerce orders into NetSuite for accounting and fulfillment.

What This Integration Does

BigCommerce is great at taking orders, but NetSuite is where finance closes the books and the warehouse pulls picks. Re-typing orders from one to the other costs hours every day and introduces mismatches in totals, tax, and customer records. This workflow takes BigCommerce orders the moment they hit a chosen status and creates the corresponding sales orders in NetSuite, with the customer record resolved (or created) up front.

You can run it via webhook for near-real-time sync, or on a schedule that polls every few minutes. Each BigCommerce order id is stored on the NetSuite sales order so re-runs detect already-synced orders and skip them, making the workflow safe to re-trigger.

Prerequisites

A BigCommerce connection with API token scoped for orders, customers, and products (read).
A NetSuite connection with permission to create customers and sales orders and run SuiteQL.
An item-mapping decision: SKU is the natural key, but you'll need each SKU to exist in NetSuite before it can land on a sales order.

Step 1: Schedule (or Webhook) Trigger

Add a Trigger node. For low-volume stores a Schedule trigger every 10 minutes is enough; for higher volume set up a BigCommerce store/order/created webhook pointing at a Webhook trigger. Either way, capture a since timestamp variable so polling stays incremental.

Step 2: List Orders from BigCommerce

Add a Connector node pointing at bigcommerce with the list-orders tool. Filter by date and status:

min_date_modified={{ since }}
status_id=11   # Awaiting Fulfillment

Page until the response array is empty - BigCommerce returns 50 per page by default.

Step 3: Loop and Resolve the Customer in NetSuite

Wrap the remaining steps in a Loop over the order array. For each order, run netsuite list-customers filtered by email. If nothing comes back, call create-customer with the BigCommerce billing address. Capture the NetSuite customer internal id in nsCustomerId via a Transform step.

Step 4: Transform the Order Payload

BigCommerce returns line items as a flat array. Use a Transform node to:

Look up the NetSuite item internal id for each line's SKU (preload a SKU-to-id map for performance).
Carry price_ex_tax through as the line rate.
Stash order.id in a custom field (or otherrefnum) for traceability.

Step 5: Create the NetSuite Sales Order

Add a Connector node calling netsuite create-record with type salesOrder:

{
  "entity": { "id": "{{ nsCustomerId }}" },
  "otherrefnum": "{{ order.id }}",
  "trandate": "{{ order.date_created }}",
  "item": {
    "items": [
      { "item": { "id": "{{ line.nsItemId }}" }, "quantity": {{ line.quantity }}, "rate": {{ line.price_ex_tax }} }
    ]
  }
}

Step 6: Confirm and Alert on Failure

Add a Condition on the response. On success, optionally call bigcommerce get-order + a follow-up update to attach the NetSuite id as order metadata. On failure, route to slack send-message with the BigCommerce order id and the error message so on-call can investigate.

Tips

BigCommerce status ids are numeric and stable. Build a small lookup in a Transform step so your filter is readable.
Cache the SKU-to-NetSuite-item map in MongoDB and refresh nightly - it removes one SuiteQL call per line.
Set retries on the NetSuite step but keep them idempotent by using otherrefnum as the natural key.

Common Pitfalls

Tax inclusive vs exclusive - BigCommerce can quote both. Pick one (usually price_ex_tax) and configure NetSuite tax codes to match, or totals will drift.
Missing SKUs - If a BigCommerce SKU has no NetSuite item yet, the order will fail. Branch on a missing mapping and post to Slack rather than failing the whole loop.
Refunds and edits - This pattern creates orders, not updates them. Subsequent BigCommerce edits won't propagate unless you build a second workflow that detects status transitions.

Testing

Trigger the workflow manually with a single test order on a sandbox NetSuite instance. Verify the customer is resolved (not duplicated) and that each line lands with the right item, quantity, and rate. Re-run the same order to confirm the duplicate is caught. Then point it at production.