BigCommerce exposes two API surfaces: the REST Management API for back-office operations (products, customers, orders, webhooks, bulk operations) and the GraphQL Storefront API for read-heavy storefront data with token-scoped access. The split is not cosmetic. REST Management uses OAuth with scoped access tokens issued per app and carries rate limits that vary by plan tier. GraphQL Storefront uses short-lived tokens scoped to specific operations and is the data layer for Catalyst and other headless storefronts. Getting the integration architecture right means picking the correct surface for each use case before the first webhook fires, because swapping later is not free.
This guide covers the integration patterns that ship most often on BigCommerce in 2026. The B2B setup guide expands on the B2B-specific API objects (company accounts, quotes, invoice portal), and the cost breakdown covers the budget implications of integration scope. Authoritative API documentation sits at the BigCommerce developer documentation.
REST Management and GraphQL Storefront
REST Management is the right choice for writes. Creating a product, updating inventory, processing an order refund, creating a customer group, importing price lists: all of it runs through REST Management endpoints with POST, PUT, PATCH, and DELETE verbs. The API is well-documented, stable, and versioned. Catalog v3 has been the current version for several years. Orders, customers, and webhooks each have their own versioning paths that evolve more slowly.
GraphQL Storefront is the right choice for reads on headless storefronts. It exposes products, categories, search, cart, and checkout state through a schema that supports query batching and selective field retrieval. The value over REST is that a Catalyst page requesting a product with its variants, images, custom fields, and price can make one request instead of four. Storefront tokens are scoped to specific channels and carry complexity limits that prevent runaway queries, with the complexity surface documented in the developer portal.
Storefront REST exists as a third surface for cart, checkout, and storefront operations from the browser. It is narrower than Management and is typically used by the Checkout SDK and by client-side carts. The Storefront Checkout API carries the same CORS constraint covered in the checkout optimization guide, which matters for any design that tries to drive checkout from a separate origin.
Webhook events and delivery behavior
BigCommerce webhooks fire on store events (order created, product updated, customer created, refund issued, shipment created, and many others) and deliver a JSON payload to a configured destination URL. The payload shape includes the event scope (for example store/order/created), the store hash, and a reference to the affected object rather than the full object body. The consumer has to call the REST Management API to fetch the current state of the referenced object, which is the single most common mistake teams new to BigCommerce make when building integrations.
Delivery behavior is at-least-once with retry on failure. A webhook endpoint that returns a 5xx response will get retried on an exponential backoff schedule. A webhook endpoint that is consistently down will eventually have its delivery disabled by the platform, which the integration needs to monitor. The practical upshot is that every webhook handler needs idempotency built in: the same event may arrive twice, and the handler must be safe to run twice without double-applying the effect.
A production integration to an ERP or CRM typically sends webhook traffic through a middleware layer that queues, deduplicates, and reconciles rather than calling the downstream system directly. Direct webhook-to-ERP integration works at low volume. At 10,000 orders per month or more, the reliability and backpressure characteristics argue for a queue (AWS SQS, Azure Service Bus, Google Pub/Sub) as the first hop.
ERP integrations: NetSuite, SAP Business One, QuickBooks
Three ERPs dominate BigCommerce integration work in 2026. NetSuite sits at the enterprise end. SAP Business One covers mid-market manufacturing and distribution. QuickBooks covers small and mid-sized retail and distribution. Each one has platform-specific field mapping challenges that agencies absorb on the first project and carry forward.
NetSuite maps item records, matrix items, price levels, and customer hierarchies against BigCommerce's products, variants, price lists, and customer groups. The nontrivial mapping is matrix items (parent with child variants) against BigCommerce variants, where the 250 option value per option limit and the broader product variant cap set hard upper bounds on how many configurations a single parent can represent. Customer-specific pricing on NetSuite item price levels maps cleanly to BigCommerce price lists for customer groups, less cleanly to per-customer overrides.
SAP Business One maps similarly but with stronger native multi-warehouse inventory logic that does not have an exact analog on BigCommerce. Stores running SAP with three or more warehouses usually build the warehouse-to-store inventory calculation in middleware rather than in BigCommerce itself, pushing a single consolidated stock value to the platform and keeping the warehouse breakdown in the ERP.
QuickBooks integrations are the most common and often the simplest. Marketplace apps handle most of the common flows out of the box for QuickBooks Online, with fewer custom cases. QuickBooks Desktop integrations are harder because of the file-based architecture and usually require an intermediate service like OneSaas, Webgility, or a custom bridge.
Agencies that have shipped ERP integrations before rarely start from scratch. Experienced teams typically maintain a field-mapping template per ERP that accelerates discovery and catches edge cases that generalist teams have to discover on the invoice.
CRM integrations: Salesforce, HubSpot
Salesforce and HubSpot dominate the BigCommerce CRM integration work. The data flow pattern is usually: BigCommerce order or customer event triggers a sync that creates or updates the corresponding CRM record, and CRM marketing automations trigger storefront events (for example, an abandoned cart email sequence). The gotchas are on the identity layer.
Email address is the common lookup key, but email is not globally unique in a B2B context where the same address can belong to multiple company accounts. Salesforce Account and Contact objects need explicit mapping to BigCommerce company accounts and customer records. HubSpot's Company and Contact model maps similarly. A small middleware layer that assigns a canonical ID on either side and reconciles both directions is usually cleaner than trying to use email as the primary key.
Consent and marketing subscription state are the second gotcha. BigCommerce carries a subscription flag on the customer record. Salesforce Marketing Cloud and HubSpot each carry their own consent model with its own state. Keeping these aligned across systems requires an authoritative side (usually the CRM for GDPR-sensitive merchants) and a webhook that propagates changes quickly.
PIM integrations
Merchants with more than about 5,000 SKUs or more than 15 attribute fields per SKU usually benefit from a PIM (Product Information Management) system as the authoritative source for product data. Akeneo, inriver, and Salsify are the common PIM choices in the BigCommerce ecosystem. The integration flows PIM product data into BigCommerce through either a native connector (Akeneo and inriver both publish BigCommerce connectors), a middleware layer (Boomi, MuleSoft, Jitterbit), or a custom sync via the Catalog v3 API.
The field surface to map typically includes product name, description, SKU, weight, dimensions, images, categories, brand, custom fields, and modifiers. Variants and options add complexity because the PIM usually models a product with variants differently from BigCommerce. A mid-complexity PIM integration ships in 6 to 10 weeks of integration engineering work on top of the BigCommerce build itself.
Rate limits and authentication
REST Management rate limits vary by plan tier and are returned on every response header, so the right integration pattern is adaptive throttling that reads the headers and backs off when the remaining quota is low. Hitting the rate limit returns a 429 response, and the retry-after header tells the client when to retry. Bulk operations (importing 5,000 products, updating prices across 20,000 SKUs, fetching 50,000 orders for analytics) need explicit rate-limit handling or they will fail partway through and leave the system in a half-synced state.
Authentication uses OAuth with scoped access tokens. An app creates a token with specific scopes (for example, products read/write, orders read, webhooks read/write) and the token is bound to the app and store. Rotating tokens is the right practice for long-lived integrations. Storing tokens in plaintext in a configuration file is not.
Middleware versus direct integration
Direct integration (BigCommerce webhook to ERP endpoint) works for simple flows at low volume. Middleware (iPaaS platforms like Celigo, Jitterbit, Boomi, or MuleSoft; custom queue-and-worker services on AWS or GCP) becomes the right call when any of three conditions exist: volume above a few thousand events per day, bidirectional sync where both systems can originate changes, or business logic that needs to transform the payload on the way through.
Middleware costs more upfront (an iPaaS subscription runs $2,000 to $15,000 per month on the low end for mid-market use; custom middleware on AWS runs similar after developer time) and pays back through reliability. A middleware layer can retry, queue, transform, and audit in ways a direct integration cannot. The common failure mode of direct integrations is not that they fail spectacularly. The common failure mode is that they fail silently, drift over months, and surface as a reconciliation problem that takes a week to track down.
Agencies that build the integration as part of a larger BigCommerce project typically propose the middleware pattern by default on projects with meaningful volume. Working with BigCommerce integration specialists who have shipped middleware-heavy projects before means these architecture decisions get made in discovery, rather than surfacing as change orders after the first failed webhook.