BigCommerce integration with your ERP, warehouse and suppliers

What BigCommerce is and who runs it

BigCommerce is a hosted commerce platform. The merchant runs no server: BigCommerce hosts the store, the checkout and the API. It is now one of the products of Commerce (commerce.com), next to Feedonomics for product feeds and Makeswift for page building. Its developer documentation names four plans: Standard, Plus, Pro and Enterprise.

For an integration that means two things. There is no version to stay on: a change to an endpoint reaches your store when BigCommerce ships it. And the limits are set by the plan, not by your hosting, so the plan decides how fast an ERP can push catalog and stock into the store. B2B Edition comes with its own API and its own data for companies, buyers and terms; Multi-Storefront adds channels to the same store.

What connects to BigCommerce

BigCommerce owns the order and the storefront. The ERP is the system of record for items, prices and stock. These are the flows we build as part of an e-commerce ERP integration:

An order write-back carries the ERP reference in external_order_id, with external_source naming the ERP. Reading orders by min_date_modified is how the integration finds every order that changed since its last run.

How BigCommerce exposes data

V2, V3 and the API gateway

Every request goes to https://api.bigcommerce.com/stores/{store_hash}/ with /v2/ or /v3/ after it. Orders, order products and shipments are still V2. Products, customers, categories and options moved to V3, and their V2 endpoints are deprecated. An integration built years ago on /v2/products still answers, but BigCommerce gives deprecated endpoints no new features, so it moves to V3 before it is extended.

API accounts and tokens

A merchant creates a store-level API account in the control panel. It comes with a static access token, sent as X-Auth-Token, which does not expire and cannot be revoked except by deleting the account. Its scopes cannot be changed afterwards either: an integration that needs one more scope needs a new account. Webhooks, metafields and scripts belong to the API account that created them, so deleting that account deletes them too. The integration gets its own account with the minimum scopes, separate from every app and every person.

Rate limits

All apps on the store draw on the same quota. A request over it gets 429 Too Many Requests with X-Rate-Limit-Time-Reset-Ms, the wait in milliseconds. A 429 without those headers means the platform is under high load and the request should be retried later. BigCommerce's rate limit page has the headers.

Worked through for one hour on Standard, 20,000 requests: an update of 4,000 products at 10 per request is 400 requests; 12,000 variants at 50 per request is 240; stock for 12,000 SKUs at 2,000 per request is 6; 24,000 price records at 1,000 per request is 24; 500 orders at 3 reads each is 1,500. Together 2,170 requests, about 11 percent of the hour. Stock across locations counts per item and location: 2,000 SKUs at 1 location fit in one request, 200 SKUs at 10 locations as well. The real constraint is the apps that share the quota, so the integration reads X-Rate-Limit-Requests-Left and backs off before it reaches zero. Integration throughput covers the arithmetic in general.

Webhooks

A webhook carries the ID of what changed, not the record. The integration reads the record with a separate call. BigCommerce retries a failed delivery 11 times, from 60 seconds to 24 hours apart, and deactivates the webhook after 48 hours with an email. When fewer than 90 percent of deliveries to a domain succeed within two minutes, the domain is blocked for three minutes. The integration answers 200 at once, processes from a queue, and polls on min_date_modified as a second route; webhooks are not a guarantee explains why both.

Where a BigCommerce integration gets stuck

Variants and catalog limits

A product holds at most 600 SKUs and an option at most 250 values. An ERP item family with 12 sizes and 60 colors has 720 combinations and has to be split across two products. Catalog writes go in batches of 10 products or 50 variants per request, so a range change in the ERP becomes a series of calls in a fixed order: product, options, variants.

Stock per location, buffers and backorders

Stock lives per location: up to 4 on Standard, 5 on Plus, 8 on Pro and 100 on Enterprise. The integration writes absolute adjustments, one request after the other: BigCommerce's documentation warns that bulk inventory operations in parallel with bulk catalog or order operations can produce incorrect results. A buffer goes into safety_stock, and BigCommerce shows available_to_sell as on hand minus that buffer: 30 on hand with a buffer of 10 is 20 for sale.

Backorders add a backorder_limit per item and location. An order for more than stock plus the limit is refused with a 409 that names the variant, the location and both quantities. An ERP with a purchase order of 45 units arriving next week can write 45 as the limit, and the order line then carries quantity_backordered. See which stock counts.

Price lists, groups and the fallback order

A price list holds records per variant and currency: price, sale_price, retail_price, map_price and bulk_pricing_tiers, up to 1,000 records per request. A list applies to a customer group and channel, and a customer belongs to exactly one group. Cascading price lists, in open beta, add up to five fallback layers behind a primary list, checked in order before the catalog price.

For an ERP with a base dealer price and customer-specific exceptions, that changes the load. Without layers, every dealer list repeats the full base list. With layers, the dealer list holds only the exceptions and falls back to a shared base list: for 8,000 SKUs and 3 dealer groups with 200 exceptions each, 8,600 records instead of 24,000. Price list changes fire no product webhook. Details in customer-specific pricing.

Customers per storefront and tax

With Multi-Storefront, a customer email is unique per channel, not per store: one buyer can have an account on each storefront, and the ERP needs one debtor for all of them. Every order carries channel_id. On tax, the order arrives with total_tax, subtotal_ex_tax and a tax_provider_id; if the ERP recalculates tax, the two differ on some orders. One side calculates and the other takes its numbers. Money, tax and rounding covers the rules.

Systems we integrate with BigCommerce

Each ERP stores items, prices and customers in its own way, so each pair has its own page:

• BigCommerce NetSuite integration: B2B Edition companies against the customer hierarchy, price lists against price levels, credit and payment terms from NetSuite.
• BigCommerce ERP integration: the general case for other ERPs.

BigCommerce EDI integration covers orders from retail trading partners, and BigCommerce PunchOut covers buyers ordering from a procurement system. The system side is on NetSuite, Business Central and Odoo.

We build the integration for a fixed price, then host it, monitor it and adjust it when BigCommerce changes an endpoint, for a monthly fee. Before go-live it runs as a dry run that writes nothing: you see per product which stock, price record and backorder limit it would set. Every integration comes with a dashboard, logs and a per-run diff. Tell us which plan and storefronts you run.