BigCommerce NetSuite integration

What moves between BigCommerce and NetSuite

BigCommerce takes the order, for consumers and for company accounts. NetSuite owns items, prices, credit and the books. With B2B Edition in use the data sits in two BigCommerce APIs, and the integration reads both.

The sales order keeps the BigCommerce order ID as its external ID. In the other direction BigCommerce has a field for it: external_order_id, with external_source naming the ERP.

Which system owns what

What BigCommerce and NetSuite store differently

Companies and the customer hierarchy

A B2B Edition company has users with roles: admin, senior buyer, junior buyer. A hierarchy holds up to 5 layers and 500 companies. NetSuite's customer hierarchy holds up to 10,000 customers. A NetSuite parent with 800 ship-to subcustomers therefore does not fit as one B2B Edition hierarchy. The mapping decides per customer: a subcustomer that orders for itself becomes a company, one that is only a delivery point becomes an address.

A company links to one customer group, and a BigCommerce customer belongs to exactly one group. That group is what price lists attach to.

Price lists and price levels

A price list record holds price, sale_price, retail_price, map_price and bulk_pricing_tiers per variant and currency:

{
  "sku": "TS-BLK-M",
  "currency": "usd",
  "price": 36.00,
  "bulk_pricing_tiers": [
    { "quantity_min": 10, "quantity_max": 49, "type": "fixed", "amount": 31.50 },
    { "quantity_min": 50, "type": "fixed", "amount": 28.00 }
  ]
}

NetSuite stacks: a customer has a price level and can have item prices of their own on top. In BigCommerce that customer needs a price list and a customer group of their own. Without layers that list holds every price, resolved in advance. Cascading price lists, in open beta and available to all stores, add up to five fallback lists to a primary list: BigCommerce checks the primary list, then each layer in order, then the catalog price. The customer's own list then holds only their item prices, with the price level's list as its layer in layers. For 3 price levels and 8,000 SKUs the load is 24,000 records: 24 requests of 1,000, sent one after the other, since more parallel upserts than BigCommerce allows on one store return a 429. Price list changes fire no product webhook, so nothing else in your stack hears about them. See customer-specific pricing.

Payment terms and credit

B2B Edition accepts six payment term values: 0, 5, 15, 30, 45 and 60 days. NetSuite terms are free records: Net 30, Net 90, 2% 10 Net 30. Net 90 and any discount term have no equal on the BigCommerce side. They need a mapping table and a decision for each term without a match.

Credit is calculated in NetSuite. From the customer's credit limit the integration subtracts the open balance and the unbilled orders and writes the result to availableCredit. NetSuite's credit hold becomes creditHold, and limitPurchases decides whether checkout blocks an order above the available amount. More in B2B terms.

The PO number

The buyer's PO number is on the B2B Edition order as poNumber, not on the /v2/orders record. One B2B order therefore takes four reads: the order, its products, its shipping addresses, and the B2B Edition order. The webhook that announces it carries only the order ID.

Tax

A BigCommerce order arrives with total_tax, subtotal_ex_tax and a tax_provider_id: BasicTaxProvider for manual tax rules, AvaTaxProvider for automatic tax. If NetSuite calculates tax again on the sales order, every order where the two differ carries the wrong amount into the books. One side is the source and the other takes its numbers. A total_tax of 0 also does not mean the customer is exempt: exemption is on the customer record, in tax_exempt_category, and maps to the customer's tax status in NetSuite.

Variants

BigCommerce allows 600 SKUs per product and 250 values per option. A NetSuite matrix allows 2,000 combinations. A matrix of 12 sizes and 60 colors has 720 children and has to be split into two products. Details in variant mapping.

The technical reality of this pair

The plan names are those of BigCommerce's developer documentation. Enterprise limits are set per plan.

Orders, worked through. At 4 reads per B2B order and 150 requests per 30 seconds, the BigCommerce API carries 37 orders per window if nothing else uses the quota. It rarely has the quota alone: a reviews app, a search app and a shipping app draw on the same 150. The B2B Edition call is the tighter one: 150 a minute is 150 B2B orders a minute at most. NetSuite then writes at its own rate: 2 slots at 3 seconds per sales order is 40 orders a minute. The integration reads X-Rate-Limit-Requests-Left on every response and slows down before the quota runs out.

Catalog, worked through. An update of 4,000 products at 10 per request is 400 requests: three windows of 30 seconds on Standard, if the quota is free. The same 4,000 as 12,000 variant updates at 50 per request is 240 requests. Stock for those 12,000 SKUs is 6 inventory requests of 2,000, each sent after the previous one returned 200. BigCommerce's documentation warns against running bulk inventory updates in parallel with bulk catalog or order updates, so the integration runs them in turn.

Webhooks. A webhook payload holds the ID and nothing else. BigCommerce retries a failed delivery after 60 seconds, then at growing intervals up to 24 hours, 11 times in all, and deactivates the webhook after 48 hours with an email to the store. If fewer than 90 percent of deliveries to a domain succeed within two minutes, the domain is blocked for three minutes. An endpoint that does its work before answering runs into that on a busy day. Ours answers 200 and queues.

The BigCommerce side is on the BigCommerce page. The NetSuite side of these numbers is on the NetSuite page and in NetSuite concurrency limits; the retry pattern is in API throttling and backoff.

Where standard connectors stop

The standard path of a packaged connector is the consumer store: orders in, shipments out, one price and one quantity out. The B2B half of this pair adds four things to that path.

• The second API. PO numbers, companies, payment terms and credit are in the B2B Edition API, with its own token headers (X-Auth-Token plus X-Store-Hash since September 30, 2025) and its own limit. A connector built on /v2/orders alone delivers the order without the PO number.
• Price lists as a model. A price list per price level, with quantity tiers, per channel and per customer group, is a model, not a field mapping. So is a price list per customer.
• Six payment terms. A fixed mapping breaks on the first NetSuite term outside 0, 5, 15, 30, 45 and 60 days.
• Several storefronts. channel_id has to become a subsidiary, class or location in NetSuite, and one buyer with an account on two storefronts has to become one customer.

A built integration carries these as rules written for your account. The technical comparison is in custom integration vs iPaaS.

When it goes wrong

An order that still fails after its retries is kept with its payload and can be sent again after the cause is fixed. Nothing is dropped without a trace.

Before go-live the integration runs as a dry run: it reads both BigCommerce APIs and NetSuite and shows the sales orders, price lists and credit amounts it would write, without writing. From then on every run leaves a diff per record in the dashboard. We host and monitor it as part of an e-commerce ERP integration, and adjust it when BigCommerce or Oracle changes an interface. Sibling pages: Shopify NetSuite integration, Magento NetSuite integration and WooCommerce NetSuite integration. Tell us how your BigCommerce store and NetSuite account are set up.