Changelog

Catalog Enrichment is live for eligible stores

Catalog Enrichment is out of beta and live now for eligible stores. It is a paid AI tool in the control panel that reads your existing product data and generates content optimized for search engines and answer engines, such as ChatGPT and Google’s AI results.

• What it generates — content for seven product fields: product name, description, SEO meta description, and SEO page title, plus AI snippet, intent Q&A, and conversational Q&A custom fields for answer engines
• Why it matters — richer, product-specific content gives search engines and answer engines more to read and cite, which can improve how often your products appear in search results and AI responses, without writing content for every product by hand
• You stay in control — guide the voice with brand guidelines and additional context, check quality scores, and review results before you apply them

Your store is eligible if it meets all of the following:

• Latest Add/Edit Product experience — the store uses the latest Add/Edit Product experience (v3 catalog)
• Latest product list — the store uses the latest product list; to migrate to it, contact BigCommerce support
• US English catalog — the catalog content is in US English

For details, see What is Catalog Enrichment?.

New guide: Protect a Catalyst storefront on Vercel from traffic spikes

A new guide covers how to prepare a Catalyst storefront hosted on Vercel for high-demand launches and bot traffic, so unwanted requests are stopped before they reach your functions and the BigCommerce APIs.

• Bot protection — turn on Vercel’s bot protection and AI bots rulesets in log mode, then move to challenge
• Rate limiting — limit add to cart, cart updates, checkout, login, registration, search, and /graphql
• BotID — verify Server Actions such as add to cart with Vercel BotID
• Caching and launch readiness — keep the Data Cache effective, coordinate load tests, and monitor the launch

For details, see Protect a Vercel Storefront from Traffic Spikes.

B2B account registration settings in the Storefront GraphQL API

Headless storefronts can now read which account types shoppers can register for, so a registration page can match the account registration setting in B2B Edition.

• Account types: the accountRegistration field on site.settings.b2b.config returns isBusinessAccountEnabled and isPersonalAccountEnabled.
• Channel-aware: the values reflect the storefront channel of the request, including a channel-level override of the store-wide setting.
• Fallback: the field returns null when the store has no B2B account registration settings. In that case, show standard registration. If the settings can’t be retrieved, the field is also null and the response includes an error with the code UPSTREAM_ERROR.

Checkout handoff instructions on createCartRedirectUrls

The createCartRedirectUrls mutation in the GraphQL Storefront API now returns externalCheckoutHandoff, which describes how to send a shopper to the external checkout as well as where, so a headless storefront can follow it without knowing which payment method the cart is using.

• A transport, not just a URL. externalCheckoutHandoff returns a url, a method of REDIRECT or POST, and the fields to submit when the method is POST. Branch on method once and the same code keeps working as payment methods are added.
• Why a POST is sometimes needed. Some wallet payloads are too large to travel in a URL. When that applies, the method is POST and the token moves into fields instead of the query string.
• Existing fields are unchanged. redirectedCheckoutUrl, embeddedCheckoutUrl and externalCheckoutUrl keep their current values. Prefer externalCheckoutHandoff over externalCheckoutUrl, which cannot carry every payment method’s payload.
• Rolling out per store. Until the POST transport is enabled for a store, method is REDIRECT and fields is empty, which is how clients behave today.

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

Storefront Session Sync GraphQL example corrections

The GraphQL examples on the Storefront Session Sync page now match the Storefront GraphQL schema. The earlier examples failed schema validation. The API itself is unchanged.

• mcp namespace: both generateSessionSyncToken and applySessionSyncCode are fields of the mcp mutation namespace, so the examples now wrap them in mcp { ... }.
• Result wrapper: both mutations return a result object and an errors list. Select token and success through result, and read errors with errors { ... on Error { message } }. The token is in the response at data.mcp.generateSessionSyncToken.result.token.
• applySessionSyncCode input: the mutation takes an input argument, so pass the code as input: { code: $code } instead of code: $code.

If you copied the earlier examples, update your queries to match. For details, see Storefront Session Sync.

USPS shipment tracking links point to the current USPS tracking page

We fixed the generated_tracking_link that the V2 Order Shipments API returns for USPS shipments. It now links to the current USPS tracking page instead of a legacy USPS URL.

• Tracking link: USPS shipment tracking links now use https://tools.usps.com/go/TrackConfirmAction?tLabels={tracking_number}. Before this fix, they used the legacy http://trkcnfrm1.smi.usps.com/PTSInternetWeb/InterLabelInquiry.do?strOrigTrackNum={tracking_number} URL.
• Custom tracking links: custom tracking_link values you supply on a shipment don’t change.

If your app parses or matches against the legacy USPS URL, update it to accept the new format.

For details, see the Get Order Shipments reference.