Skip to navigation

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.


External source attribution for carts and checkouts in the GraphQL Storefront API

BigCommerce is rolling out an optional externalSource field on cart and checkout creation in the GraphQL Storefront API, so a caller can record where a cart originated and read that attribution back.

  • Set the source on creation. The createCart and createCheckout mutations accept an optional externalSource string on CreateCartInput and CreateCheckoutInput, naming the external source the cart or checkout originated from.
  • Read the attribution back. The Cart type returns the stored value as externalSource. Checkouts expose it through their associated cart as checkout.cart.externalSource.
  • Omitting the field changes nothing. externalSource is optional on both inputs, so existing queries and mutations continue to work unchanged.

For details, see GraphQL Storefront API: Carts and Checkout.


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.