BigCommerce integration, end to end

Section 01

API V3, the integration surface

V3 is the modern API. There is also a V2 still alive for orders and a few legacy resources, but a fresh integration uses V3 wherever V3 exists. The base URL is https://api.bigcommerce.com/stores/STORE_HASH/v3.^[1]

Authentication

Two valid auth shapes: an OAuth app installed from the BigCommerce App Marketplace, or a store-level API account credential generated by the merchant.^[5] For 3PLs onboarding a single brand, the store-level account is faster. For a 3PL that wants to support self-serve connection, the OAuth app is the right call.

Section 03

Multi-storefront and Channels

Channels are BigCommerce's term for selling surfaces: multiple branded storefronts, headless front ends, marketplaces, B2B portals.^[3] Each Channel has its own context for product visibility, pricing, customer groups, and inventory pools.

“The reason BigCommerce gets picked over Shopify for multi-brand groups is almost always Channels. One catalog, one inventory pool, many storefronts, clean per-channel pricing.^[9]”

Inventory split decisions

For 3PLs supporting multi-storefront brands, the question is whether to pool inventory across all channels or split it. The default we recommend is pooling. Splitting is right when one channel has guaranteed demand (a wholesale account, a marketplace contract) and you want to reserve units against that demand without surfacing them to DTC.^[4]

Section 05

Operational practice

Tracking back

We post tracking through /orders/{id}/shipments with the per-line-item quantities and the carrier and tracking number. A single order can have multiple shipments first-class, which is the right model for split-pack and pre-order brands.^[8]

Inventory writes

The Inventory API accepts adjustments as deltas with a location identifier. We write deltas, never absolute sets, and tag the adjustment with a reason code so the brand admin can audit them.^[4]

Reconciliation cadence

Hourly diff for inventory. Nightly diff for orders. Same model as the rest of our connector library, because the failure modes are the same: webhooks that retried and gave up, transient outages on either side, manual edits we were not informed about.

Section 07

Headless commerce, Catalyst, and the storefront API

BigCommerce's headless story is more developed than most platforms in the category. Catalyst is BigCommerce's reference Next.js storefront, and the storefront-side GraphQL API (the Storefront API) sits next to the management-side V3 API.^[11]

Two APIs, one platform

The storefront API is what a custom front end queries to render product pages, build a cart, and render checkout. The V3 management API is what the integration uses to fulfill orders and write inventory. They never compete; the front end never writes inventory, and the integration never reads cart state. Keeping them separate is what makes headless safe to run.

Cart and checkout in headless mode

BigCommerce's Open Checkout and Catalyst both use BigCommerce's payment and tax engine even when the front end is custom. The completed order lands in BigCommerce as a normal order, our webhook fires, and the integration treats it identically to an order from a Stencil-themed storefront. This is the contrast with platforms where headless requires a separate fulfillment integration; here it does not.

Why headless adoption is rising

Two reasons. First, performance: a Next.js front end on Vercel or Cloudflare Pages outperforms a Stencil theme on shared infrastructure for page-load time, which affects conversion. Second, design freedom: the brand owns the entire visual surface. The cost is engineering ownership; somebody on the brand side has to maintain the front end. For brands above $20M who can support that engineering, the trade-off is favorable.^[13]

Section 09

Pricing tiers and Enterprise features that affect integrations

BigCommerce has four tiers: Standard, Plus, Pro, and Enterprise. The integration surface is broadly the same across all four; the differences that matter for fulfillment are mostly volume-related.^[7]

API call limits

Standard tier limits API calls per second. Enterprise tier raises that limit and allows for negotiated higher caps. For a 3PL onboarding a brand with a large catalog, the practical effect is that catalog backfill goes faster on Enterprise. We use bulk endpoints where available and pace the backfill against the tier's limits, but Enterprise is noticeably less constrained.

Multi-storefront and Enterprise

Multi-Storefront is an Enterprise-tier feature. Brands running multiple storefronts are usually on Enterprise, which also includes priority support and the option to negotiate uptime SLAs. The integration treats each storefront as a Channel and operates them through the same connector instance.

Stencil and theme considerations

Stencil is BigCommerce's theme system for non-headless storefronts. Stencil customizations live in the brand's theme repo and can introduce order shape changes through cart customizations or custom checkout modifications. We audit Stencil customizations during onboarding to identify any field name overrides that could affect order parsing. Customizations using the standard theme APIs do not affect the integration; only the rare "edit-the-theme-PHP" patterns do.

Going from one tier to the next

Tier upgrades happen with no integration changes required. The brand's auth tokens stay valid, the API base URL stays the same, and the webhook subscriptions roll forward. We do bump the rate-limit headroom we plan for after an upgrade, since the brand's traffic shape often grows along with the tier.

Section 11

The checks we run quietly on every BigCommerce store

The day-to-day reliability of a BigCommerce integration depends on a short list of automated checks running continuously. We do not page on all of them, but every one of them is graphed.

• Webhook delivery success rate, per topic, sliding hour window. Below 99.5 percent triggers investigation, below 95 percent pages on-call.
• API call rate vs tier limit, with alerts at 70 percent of the budget so we can throttle before we hit a hard limit.
• Reconciler delta count, daily. A non-zero count is normal; a sudden spike signals an upstream change in webhook delivery or an out-of-band edit by a brand admin.
• Inventory variance per channel, especially for multi-storefront brands where one channel's writes can lag another's reads.
• Open shipments older than the brand's promised SLA. These are the tickets that are about to come in if we do not catch them first.
• V2 endpoint usage. We track when the integration falls back to V2 so we can move endpoints to V3 as BigCommerce releases them.

The brand-facing console

The same metrics surface in the brand admin, scoped to that brand's store. They see the same numbers we do, refreshed in near-real-time. The transparency is the point. A brand that can verify the integration is running cleanly does not need to ask. A brand that sees a spike and knows what it means before we call them sees us as partners rather than vendors.

The console is also where the brand answers their own customer questions. When a customer service rep needs to confirm whether an order has shipped, they look at the console rather than emailing us. The end result is fewer support tickets, faster customer responses, and a tighter loop between the brand's customer-facing team and the warehouse floor. We measure how often the brand opens a support ticket against how often the integration's brand console answered the question without one. That ratio improves over time as the console gains the answers the team needed last week.