BigCommerce ERP integration

What moves between BigCommerce and an ERP

BigCommerce takes the order and the payment. The ERP holds items, prices, stock, customers on account and the books. The flows are the same whichever ERP sits behind the store; the endpoints on the BigCommerce side are fixed.

Orders and shipments are on the V2 Orders API; transactions and refunds are on V3. A B2B store adds the B2B Edition API, with its own limit of 150 requests per minute and the buyer's poNumber, which the V2 order does not carry. The B2B side with NetSuite is worked out on BigCommerce NetSuite integration.

What BigCommerce's API allows

One quota for the whole store

Each request costs one unit, and the quota is shared by every app on the store. The integration's share shrinks when a search app or a reviews app is busy. Every response carries the state of the window:

X-Rate-Limit-Time-Window-Ms: 30000
X-Rate-Limit-Time-Reset-Ms: 15000
X-Rate-Limit-Requests-Quota: 150
X-Rate-Limit-Requests-Left: 35

Above the quota BigCommerce answers 429. Its developer documentation treats an integration that keeps sending after consecutive 429s as abusive and reserves the right to throttle or disable it, even on the Enterprise rate plan without a request limit. So the integration slows down when X-Rate-Limit-Requests-Left runs low, not after the first 429.

Orders, worked through

A webhook carries the order ID and nothing else. Reading one order takes three requests: the order, its products, its shipping addresses. On a Standard plan that is at most 50 orders per window if the integration had the quota to itself. A sale day with 1,200 orders in an hour is 3,600 reads: 24 windows of 150, or 12 minutes of the store's entire quota, spread over the hour by the queue so the other apps keep working.

Catalog, worked through

Collection endpoints return 50 records per page by default. BigCommerce's own example: reading 5,000 products at the default is 100 requests, at limit=250 it is 20. Writes have their own batch sizes. Stock for 12,000 SKUs is 6 absolute adjustments of 2,000 items, sent one after the other, because BigCommerce advises against running bulk inventory updates in parallel with bulk catalog or order updates.

Webhooks

BigCommerce retries a failed webhook 11 times, from 60 seconds up to 24 hours apart, and deactivates it 48 hours after the first attempt with an email to the app owner. Below 90 percent success over two minutes the receiving domain is blocked for three minutes. A subscription with no events for 90 days is also deactivated, which happens to stores that sell seasonally. The integration therefore checks is_active on its hooks and polls orders by min_date_modified. More in webhooks are not a guarantee.

What BigCommerce and an ERP store differently

Order statuses

BigCommerce has fixed status IDs; the label can be renamed per store, the ID cannot. The ERP has its own document states. The mapping decides which statuses create a sales order and which only update one.

Two details from BigCommerce's documentation matter here. Deleting a shipment does not move an order out of Shipped. And an order created as Awaiting Fulfillment and then edited by hand does not adjust stock in BigCommerce, so the ERP's quantity and the store's differ until the next stock run. The full mapping question is in order status mapping.

Variants and modifiers

In BigCommerce every purchasable item is a variant; a product without options is its own base variant. Variant options build SKUs. Modifier options do not: engraving text, a gift-wrap checkbox or a delivery note change what happens to the item, not which SKU leaves the shelf, and BigCommerce cannot track stock against them. A modifier can carry a price adjuster. A shirt at 24.00 with engraving at plus 5.00 arrives as an order line of 29.00 on the shirt's SKU. Written as is, the ERP books 29.00 against an item priced at 24.00. The integration writes 24.00 on the item line, the 5.00 on a charge line, and the engraving text as line text. BigCommerce allows 600 SKUs per product; an ERP matrix that is larger is split.

Prices and tax

A price list record holds price, sale_price, retail_price, map_price and bulk_pricing_tiers per variant and currency. One price list applies to a customer at a time, through the customer's single customer group. An ERP that stacks a price level, a customer price and a quantity break needs every price resolved before it reaches BigCommerce. See customer-specific pricing.

Order lines carry price_ex_tax and price_inc_tax, and the order carries total_tax. If the ERP recalculates tax on the sales order, the two totals differ on some orders by a cent, and the invoice no longer matches the payment. One side is set as the source of tax, once. Background in money, tax and rounding.

Which ERP

Every ERP limits its API in its own unit. These are the numbers that decide how the ERP half of a BigCommerce ERP integration is built.

NetSuite. The concurrency limit is shared with every other integration on the account, and a sales order created and saved in a script costs 30 governance units. Worked out in BigCommerce NetSuite integration.

Business Central. OAuth 2.0 only since October 2022. Above 6,000 requests in five minutes a user gets a 429, and an operation running longer than 8 minutes is stopped. The standard item API returns one inventory number, not stock per location; per-location stock needs a custom API page. More on the Business Central page.

Acumatica. Each license sets three API limits, visible on the License Monitoring Console (SM604000). At half the per-minute limit Acumatica starts to delay requests, and it declines a request once more than 20 are waiting or one has waited 10 minutes. Acumatica also ships its own BigCommerce connector in its commerce edition. More on the Acumatica page.

Sage Intacct. The XML API needs a Web Services subscription and a sender ID; Sage recommends its REST API for new work. Concurrent requests are limited per company. More on the Sage Intacct page.

QuickBooks Online. 500 requests per minute per company, 10 per second per company and app, and a request that runs longer than 120 seconds times out. Inventory tracking needs QuickBooks Online Plus or Advanced, and an item holds one QtyOnHand, without a location. More on the QuickBooks page.

Odoo. Odoo 19 added the JSON-2 API; XML-RPC and JSON-RPC are removed in Odoo 22. An API key for a normal user expires after at most 90 days, so the integration renews it before then. More on the Odoo page.

Where standard connectors stop

Standard connectors and iPaaS templates for BigCommerce cover orders in, shipments out, one price and one quantity out. Their limits follow from the BigCommerce data model:

• Modifiers. A fixed mapping writes the order line as it comes, adjuster included, so ERP margins per item are off on every order with a paid option.
• Price lists. One price per variant is a field mapping. A price list per price level and per customer, with quantity tiers and currencies, is a model.
• The quota. A connector that polls the full catalog on a timer competes with every other app for 150 requests per 30 seconds.
• The B2B Edition API. A connector built on /v2/orders alone delivers B2B orders without the PO number.
• Several storefronts. Each order has a channel_id, and customer email addresses are unique per channel, not per store. The same buyer on two storefronts has to become one ERP customer.

A built integration carries these as rules written for your store and ERP. The comparison on technical grounds is in custom integration vs iPaaS.

When it goes wrong

An order that still fails after its retries is kept with its original payload and sent again after the cause is fixed. Before go-live the integration runs as a dry run that writes nothing and shows what it would change; after that every run leaves a diff per record. This is how we build every e-commerce ERP integration. The BigCommerce side in full is on the BigCommerce page; sibling pages are Shopify ERP integration and WooCommerce ERP integration. Tell us which ERP runs behind your store.