For AI agents: a documentation index is available at the root level at /llms.txt. Append /llms.txt to any URL for a page-level index, or .md for the markdown version of any page.
LogoLogo
Dev Portal
DocsAPI ReferenceLearnCommunityChangelog
DocsAPI ReferenceLearnCommunityChangelog
Dev Portal
On this page
  • September 17, 2026
  • Filter wallet shipping options in custom checkouts
  • GraphQL Schema Updates
  • September 16, 2026
  • Catalyst 1.12.0
  • Catalyst CLI 1.4.1
  • GitHub Actions deployments for Native Hosting
  • MCP server: logged-in shopping with Storefront Session Sync and B2B Buyer Portal tools
  • Updated storefront crawler detection list
  • September 15, 2026
  • Catalog CSV import rejects files with invalid header encoding
  • Fixed unresponsive page when duplicating high-variant products
  • September 14, 2026
  • B2B order data in the Storefront GraphQL API

Changelog


September 17, 2026
September 17, 2026

September 17, 2026
September 17, 2026

September 16, 2026
September 16, 2026

September 16, 2026
September 16, 2026

September 16, 2026
September 16, 2026

September 16, 2026
September 16, 2026

September 16, 2026
September 16, 2026

September 15, 2026
September 15, 2026

September 15, 2026
September 15, 2026

September 14, 2026
September 14, 2026
Older posts
Next
Built with

Filter wallet shipping options in custom checkouts

Custom checkout implementations based on checkout-js can control which shipping options appear in Apple Pay, Google Pay, and Stripe Link V2 wallet interfaces.

  • Shipping option callback — pass filterAvailableShippingOptions from a custom wallet component to return the rates that the wallet supports.
  • Selection synchronization — when filtering removes the selected rate, the Checkout SDK selects the recommended rate or the first remaining rate.
  • Error fallback — if the callback rejects or throws an error, the wallet displays the unfiltered shipping options.
  • SDK support — use @bigcommerce/checkout-sdk version 1.978.0 or later for all three wallets.

For details, see Filter wallet shipping options.

GraphQL Schema Updates

The root company query on the Storefront GraphQL API is now deprecated. B2B company data lives under the authenticated customer’s activeCompany context, introduced in July, and integrations should migrate to it.

Storefront GraphQL

  • Query.company deprecated: query customer { activeCompany { ... } } instead. The ActiveCompany type exposes the same addresses, address, and orders fields as CompanyQueries.
  • CompanyQueries.addresses deprecated: use customer { activeCompany { addresses { ... } } }. Pagination, CompanyAddressFiltersInput filtering, and CompanyAddressSortInput sorting are unchanged.
  • No behavior change today: the deprecated fields continue to resolve. A sunset date has not been set; migrate before removal is announced.

For schema details, browse the Storefront GraphQL API reference.

Catalyst 1.12.0

Catalyst 1.12.0 serves the Universal Commerce Protocol (UCP) endpoints for agentic commerce on your storefront’s own domain, and stops a per-request header from making every Next.js Data Cache lookup miss.

  • UCP endpoints are proxied to BigCommerce — agents discover and call UCP on the storefront’s public domain, but the protocol is served by the BigCommerce platform rather than by Catalyst. /.well-known/ucp and /api/ucp/* now proxy through to BigCommerce for every HTTP method, where previously /api/ucp/* returned a 404 and /.well-known/ucp was locale-redirected. Only the headers the UCP REST transport spec defines are passed in either direction, and no new environment variable is required.
  • Customized proxies need one update — if you have customized proxy.ts, add withUcpProxy as the first argument to composeProxies and add /api/ucp/:path* to config.matcher. An unmodified proxy.ts picks both up from the upgrade.
  • Data Cache lookups hit again — X-Correlation-ID is no longer sent on cacheable GraphQL requests. Next.js builds its Data Cache key from the fetch URL, method, body, and headers, so a correlation ID regenerated on every request produced a unique key on every request. Fetches configured with next: { revalidate } could never hit: each one went out to the BigCommerce GraphQL API and wrote an entry that nothing would ever read. On a product page that is roughly 12 queries per page view. The header now follows the same rule as X-Forwarded-For, and is attached only to no-store and no-cache requests, which are uncacheable by construction.

See the full 1.12.0 release notes for migration details and release tags.

Catalyst CLI 1.4.1

The Catalyst CLI (@bigcommerce/catalyst) 1.4.1 is a patch release that breaks a login deadlock on expired tokens, stops upgrade from reverting the CLI-managed npm scripts, and cleans up two smaller upgrade and prompt issues.

  • catalyst auth login re-authenticates an expired token — every authenticated command answered a rejected token by telling you to run catalyst auth login, but login only checked whether credentials were present, not whether they still worked, and answered with “Already logged in. Run catalyst auth logout first.” The two commands sent you in a circle unless you knew to run auth logout. login now verifies the credentials it finds: working credentials exit as before, rejected ones carry straight on to re-authentication. A failure that is not a rejection, such as an unreachable API, keeps the credentials and exits rather than discarding them. --force skips verification outright.
  • catalyst auth login --store-hash <hash> --access-token <token> stores what you pass — the documented “login with existing credentials” path never wrote the credentials anywhere, so the next command was still unauthenticated. Both flags together are now verified and saved to .bigcommerce/project.json. Only the flags count: these options also read CATALYST_STORE_HASH and CATALYST_ACCESS_TOKEN, and an exported environment variable must not turn a plain catalyst auth login into a silent credential write.
  • catalyst upgrade keeps the CLI-managed npm scripts — catalyst create points build, start, and deploy at the CLI, which makes those lines a permanent difference from the upstream tree. When core 1.11.0 added "test": "vitest run" directly below "start", neither merge engine could reconcile the two, and resolving toward the incoming side silently turned catalyst start back into next start. The three keys are now pinned to the commands your project already has before the merge runs, so additions around them still apply cleanly, and a genuine upstream change to one of them is reported rather than hidden.
  • catalyst upgrade removes a reintroduced instrumentation.ts — a merge could bring back an instrumentation.ts that is incompatible with Commerce Hosting, leaving it to be deleted by hand.
  • catalyst channels info asks for the right thing — its channel picker inherited “Select the channel to update.” from channels update, implying a write that info never makes. It now asks “Select a channel.”

For details, see the Catalyst CLI reference.

GitHub Actions deployments for Native Hosting

New documentation covers deploying a Catalyst storefront to Native Hosting from GitHub Actions, both on merge to your default branch and as a preview for each pull request.

  • Deploy on merge — a workflow that authenticates the Catalyst CLI without a browser login, and passes runtime secrets so they reach the deployed application rather than only the build
  • Pull request previews — a published action that deploys pull request code and comments the URL on the pull request; the newest open pull request deploys automatically, and any other claims the preview by commenting redeploy preview
  • One preview at a time — a hosting project has one hostname rather than one per deployment, so a repository shares a single preview project and preview URL
  • Configuration and troubleshooting — the variables and secrets each workflow reads, and the misconfigurations that produce a successful build with a broken deployment

For details, see GitHub Actions.

MCP server: logged-in shopping with Storefront Session Sync and B2B Buyer Portal tools

The BigCommerce MCP server now supports authenticated shopping flows. AI agents can operate in a shopper’s existing Stencil browser session, and B2B buyers get a new tool set for shopping lists and quotes.

  • Storefront Session Sync — link an MCP session to a shopper’s existing Stencil session with a short-lived opaque token. Generate the token with the generateSessionSyncToken GraphQL mutation and pass it in the X-Bc-Storefront-Sync-Token header at MCP initialization. Login state, cart, and identity carry into the agent without exposing cookies, and reverse sync (X-Bc-Mcp-Stencil-Sync-Code) keeps the storefront in step when the agent creates a new cart.
  • Logged-in B2C shopping — the B2C Storefront tool set now supports guest and logged-in customer flows. Authentication happens through session sync rather than a dedicated customer_login tool.
  • B2B Storefront tool set — new Buyer Portal tools on the same MCP endpoint, gated per store by B2B Edition and per tool by the buyer’s permissions: 12 shopping list tools (create, update, add and remove items, submit for approval, approve, reject, duplicate) and 5 quote tools (request a quote, view details, message the sales representative, generate a checkout URL).
  • One endpoint, layered tool sets — the catalog, cart, and checkout tools stay available to every session, including guests on B2B-enabled stores; B2B tools are added on top when the buyer’s synced session qualifies.

For details, see the MCP Server overview, Storefront Session Sync, B2C Storefront, and B2B Storefront.

Updated storefront crawler detection list

The list of known crawlers and bots that storefronts use to classify incoming traffic has been refreshed to match the latest industry list, keeping crawler detection consistent across the BigCommerce platform.

  • Newer crawlers recognized — bots that have appeared recently are now identified as crawlers.
  • Outdated entries removed — patterns that are no longer in use have been dropped.
  • Fewer false positives — some in-app browsers, such as the WeChat browser, are now correctly treated as shoppers rather than crawlers.

This change is rolling out gradually to all stores.

For details on the is_crawler value exposed to Stencil themes, see the settings object reference.

Catalog CSV import rejects files with invalid header encoding

Product CSV imports now fail with a clear error when the file’s header row contains invalid character encoding, instead of importing with a corrupted column mapping.

  • Header encoding validation: the header row must use UTF-8 encoding, matching the existing requirement for data rows. A file with an invalid header now stops the import and reports which column failed.

For details, see error handling during catalog migration.

Fixed unresponsive page when duplicating high-variant products

Duplicating a product with a large number of variants (near the 600-variant limit) could make the product edit page freeze or become unresponsive.

  • Batched SKU validation — duplicate-SKU checks now run as a handful of bulk requests instead of one pair of requests per variant, cutting request volume for a 600-variant copy from over a thousand down to a handful.
  • Fixed a loading-state bug — the page could render blank before variant and modifier data finished loading; both now block rendering until their data is ready.

Interactive controls on the product edit page, such as the storefront visibility checkbox, now respond immediately even while variant data loads in the background.

For details, see the Product Variants overview.

B2B order data in the Storefront GraphQL API

Authenticated B2B company users can now read company orders and B2B order details through the Storefront GraphQL API, so a single storefront graph can serve both B2C and B2B order experiences.

Storefront GraphQL

  • Company order queries: the orders field on the ActiveCompany type returns orders placed on the current storefront channel by any user in the shopper’s active company, with cursor pagination, filtering, and sorting.
  • B2B order fields: orders add poNumber, reference, company, placedBy, invoice, history, and extraFields. These fields require a B2B storefront token.

For example queries, see the Orders guide, or browse the Storefront GraphQL API reference for schema details.