Short answer
BigCommerce integrates with ERPs through its REST APIs — Orders and shipments largely on V2, catalog on V3 — and webhooks whose payloads contain only minimal data, such as the resource ID. Your integration receives the webhook, fetches the full resource through the API, and writes it to the ERP. Plan for a rate-limit quota shared by all apps on the store, possible duplicate webhook callbacks, and reconciliation for anything missed.
BigCommerce integration surface at a glance (documented capabilities; see sources)
- APIs
- REST APIs authenticated with X-Auth-Token; Orders V2 (including shipments) and V3 resources such as the catalog.
- Webhook payloads
- Minimal data, e.g. only the order ID for store/order/statusUpdated; fetch details via the API.
- Webhook security
- Optional custom headers on the subscription to authenticate callbacks; destination must use port 443.
- Webhook retries
- Retries at increasing intervals for a little over 48 hours; duplicates can occasionally occur.
- Rate limits
- Quota per 30-second window, varying by plan, shared by all apps on the store; reported in X-Rate-Limit-* headers.
- BigCommerce Lightweight webhook
- Receiver Check header
- Worker Fetch order via V2 API
- ERP
BigCommerce is a hosted platform with a broad REST API and an event system designed around lightweight notifications. The integration pattern that fits it best is “notify, then fetch”: a webhook says something changed, and your service retrieves the details. Documented statements below come from BigCommerce’s developer documentation; recommendations are ours.
How BigCommerce connects to an ERP
Documented: BigCommerce’s REST APIs are authenticated with an access token in the X-Auth-Token header and scoped by store hash. Orders and order shipments are handled by the Orders V2 API; catalog resources such as products and variants are on V3.
Documented: webhooks are created through the API with a scope (for example store/order/created, store/order/updated, or store/order/statusUpdated) and a destination URL, which must be served on port 443. Payloads contain minimal data — for store/order/statusUpdated, only the order ID — and you fetch details through the API.
Recommendation: use a receiver that enqueues the resource ID and a worker that fetches and processes it. This matches BigCommerce’s design and keeps the receiver fast.
Common integration use cases
- Order export to the ERP.
- Inventory and price publication from the ERP.
- Product and variant creation from the ERP or a PIM.
- Shipment and tracking updates from the ERP or warehouse.
- B2B customer and price list synchronization.
Order synchronization
Documented: the Orders V2 API supports creating, reading, updating, and deleting orders, and exposes order shipments and shipping addresses.
Recommendation: subscribe to order created and status updated scopes, fetch the order and its products through the API, and export when the order reaches the status that your process treats as ready (for example, “Awaiting Fulfillment”). Use the BigCommerce order ID with the store hash as the ERP’s unique external reference.
Inventory synchronization
Documented: catalog products and variants carry inventory fields, and BigCommerce provides inventory endpoints, including support for inventory by location. Check the current inventory documentation for which endpoints suit your setup.
Recommendation: publish stock at variant level, batch updates where the API allows, and account for orders not yet in the ERP. With a shared rate-limit quota, schedule large reconciliations outside peak hours.
Product and variant synchronization
Documented: V3 catalog products have variants, each with its own SKU, created from option combinations.
Recommendation: map each variant SKU to one ERP article, and treat BigCommerce product and variant IDs as cross-reference data. See mapping products to ERP SKUs.
Customer data synchronization
Documented: customers are available through the Customers API, and guest checkouts carry billing details on the order.
Recommendation: use a generic web customer for guest orders in the ERP if your process allows, and match B2B customers on a stable stored ID.
Fulfillment and shipment updates
Documented: shipments are created with a POST to the order’s shipments endpoint (V2). You can create multiple shipments for an order by specifying a subset of products and quantities in each request.
Recommendation: create one shipment per package or per warehouse dispatch, include the tracking number and carrier, and store the ERP shipment ID → BigCommerce shipment ID link to make retries safe.
API and webhook considerations
Documented:
- Webhook callbacks may occasionally be duplicated.
- If the success ratio of callbacks to a destination domain drops below 90% within a two-minute window, the domain is blocklisted for three minutes and events are queued for retry. Retries happen at increasing intervals, for a little over 48 hours.
- Retry decisions are based on the destination domain as a whole, so different webhook URLs on the same domain affect each other.
- A webhook subscription is deactivated after 90 days of inactivity.
- You can pass custom headers when creating a webhook to authenticate callbacks.
- Rate limits use a quota refreshed every 30 seconds, varying by plan; all apps on a store share the quota. Responses include
X-Rate-Limit-Requests-Left,X-Rate-Limit-Requests-Quota,X-Rate-Limit-Time-Reset-Ms, andX-Rate-Limit-Time-Window-Msheaders.
Recommendation:
- Deduplicate webhook events by scope, resource ID, and a short time window, and make processing idempotent anyway.
- Host webhook receivers on a dedicated domain or subdomain so failures in one service do not trigger blocklisting for another.
- Read rate-limit headers on every response and pause before the quota runs out.
- Run a periodic job that lists your webhooks and confirms they are active.
Common implementation challenges
- Shared quota contention with other installed apps.
- Blocklisting after a slow or failing receiver, delaying all webhooks for the domain.
- Duplicate callbacks processed as separate orders.
- V2/V3 differences in field names and ID formats across resources.
- Variant-level inventory mistakenly written at product level.
Direct integration vs. middleware
BigCommerce has a marketplace of prebuilt ERP connectors and is supported by many iPaaS products. For established ERPs, a connector may cover standard workflows. For a custom ERP, a custom service or middleware with custom adapters is typical. See custom integration vs. off-the-shelf connectors.
Frequently asked questions
Why do BigCommerce webhooks only contain an ID?
BigCommerce documents that webhook payloads contain minimal information about the store and event, for security reasons. Your integration fetches the full order, product, or customer through the API after receiving the webhook.
How do I verify that a webhook came from BigCommerce?
When creating the webhook, you can supply a headers object. BigCommerce sends those headers with each callback, so you can include a secret value and check it on receipt. Combine this with HTTPS and validation that the store hash matches a store you serve.
Are BigCommerce rate limits per app?
BigCommerce documents that all apps accessing a store share the store's quota, which refreshes every 30 seconds and varies by plan. A busy marketplace or marketing app can reduce the capacity available to your ERP integration.
Which API do I use for orders?
BigCommerce's Orders V2 API covers reading, creating, and updating orders and managing shipments. Some order-related resources are on V3. Check the current Orders documentation for which version covers each operation you need.
Sources and further reading
Platform-specific statements on this page were checked against these sources on . Vendor APIs change; confirm details in the current documentation before you build.
- [1] Webhooks overview — BigCommerce
- [2] API rate limits — BigCommerce
- [3] Orders overview (V2 and V3) — BigCommerce
Related reading
- Guides How to Prevent Duplicate Orders in an ERP Integration Why ecommerce integrations create duplicate ERP orders — duplicate webhooks, retries after timeouts, races — and the layered defenses that stop them.
- Guides How to Implement Retries and Idempotency A practical implementation of retries with exponential backoff and jitter, plus idempotency keys, so ecommerce-ERP integrations can retry safely without side effects.
- Concepts What Are Webhooks? What webhooks are, how they deliver change notifications between systems, how to verify them, and the delivery behaviors integrations must be designed around.
- Guides How to Map Ecommerce Products to ERP Articles and SKUs Design product and variant mapping between an ecommerce platform and an ERP — SKU strategy, variants, bundles, units of measure, cross-references, and validation.
- Comparisons Webhooks vs. Polling: Choosing How Your Integration Detects Changes Compare webhooks and polling for detecting changes in integrations — latency, completeness, cost, infrastructure, and failure modes — and learn when to combine them.
- Comparisons Custom ERP Integration vs. Off-the-Shelf Connectors Compare building a custom ecommerce-ERP integration with buying a prebuilt connector — fit, cost over time, flexibility, support, and the questions to ask vendors.