Changelog

Single active storefront session per customer

Storefront customer sessions are single-active: signing a customer in again or signing them out invalidates every customer access token previously issued for that account, not just the session that triggered the change.

• One session per customer account — every sign-in method rotates the underlying session token and ends the customer’s other sessions. This covers a storefront sign-in, the Customer Login API access point URL (/login/token/{token}), the GraphQL Storefront API login and loginWithCustomerLoginJwt mutations, and flows built on them, such as a B2B Edition buyer portal sign-in. Sign-out invalidates the customer access token the same way.
• expiresAt is a latest-possible expiry, not a guaranteed lifetime — a customer access token can stop working earlier than its expiresAt value because the customer signed in again or signed out.
• Invalidated tokens do not return errors — a GraphQL request that carries an invalidated customer access token runs as an anonymous shopper: the customer field returns null, and customer-specific values such as customer-group pricing fall back to guest values. To make such requests return an explicit error instead, send the X-BC-Error-On-Invalid-Customer-Access-Token header with a value of true.
• For headless storefronts and integrations — store at most one customer access token per customer account and replace it with the newest token after each sign-in, consolidate the customer’s sign-in flows on a single method, and treat a null customer response as a signal to prompt the customer to sign in again.

For details, see Customer session behavior.

Saving SCSS in Edit Theme Files no longer fails on an unapplied Stencil theme

Saving an SCSS file in Edit Theme Files now works for a Stencil theme that is uploaded to the control panel but not applied to the store. These saves previously failed with error TR-3501 because the rebuild request timed out, not because the theme failed to compile.

• Fewer configurations per rebuild — Saving a style file recompiles the theme for each of its variations. For an unapplied theme, the rebuild used to include every saved and preview configuration ever stored for every variation, often dozens, so the request timed out. The rebuild now uses one configuration per variation: the store’s most recent saved configuration, or the variation’s default if the store has never saved one.
• Clearer error when a rebuild times out — If the rebuild still does not finish in time, the editor now shows TR-3511 (the build did not complete) instead of TR-3501 (the theme failed to compile). A theme that is slow to compile even with a single configuration can still hit this timeout.

No action is required.

Clarified how inventory_tracking affects storefront option availability

Thanks to user feedback, the V3 Catalog Products documentation now explains that a product’s inventory_tracking value also controls whether the storefront restricts option selection to combinations that exist as variants.

• variant tracking gates option-availability filtering — when the store’s out-of-stock option behavior (Settings > Inventory) is set to label or hide unavailable options, the storefront offers only the option combinations that map to a variant with stock greater than zero.
• none and product keep every combination selectable — regardless of which variants exist, so shoppers can select combinations that have no matching variant.
• Documented the trade-off — because the availability list is built only from combinations with stock greater than zero, enabling variant tracking to hide non-existent combinations also hides or labels real variants once they sell out.

For details, see the inventory_tracking field.

Custom field channel overrides now save on disabled channels

We’re rolling out a fix so that setting a channel-locale override for a product custom field no longer fails when the target channel is disabled.

• Custom field overrides — setProductCustomFieldsInformation now accepts a channel-locale override for any channel that exists, active or disabled, instead of rejecting the request as if the channel didn’t exist. Deleted and terminated channels are still rejected.

You may notice changes in this area over the coming weeks as the fix rolls out. For details, see the Product custom fields reference.

List and revoke storefront API tokens by ID

You can now list the storefront API tokens your API account has issued and revoke them by ID, without needing the token’s full JWT string. These operations are available for all three token families: storefront, private, and customer impersonation.

• List tokens - GET /storefront/api-token returns a paginated list of the tokens your API account issued. The JWT string is never returned; each entry includes a jti identifier, is_revoked and is_expired flags, and an optional name label.
• Revoke a token by ID - DELETE /storefront/api-token/{jti} revokes a single token using only its jti.
• Revoke all tokens - POST /storefront/api-token/revoke-all revokes every active token your API account issued in that family.
• Optional name - the token creation endpoints now accept an optional name label to help you identify tokens in the list.

For private and customer impersonation tokens, swap the path segment to /storefront/api-token-private or /storefront/api-token-customer-impersonation. Revocation can take up to approximately 60 seconds to fully propagate.

For details, see Managing and revoking tokens.