Storefront request context
Storefront data is resolved for a market and shopper, not only for a project. The same product can be visible, priced, translated, taxed, and available differently when the request context changes.
Build one canonical context in your application and reuse it across discovery, product detail, cart creation, and checkout. Treat context changes as commerce state changes, not presentation-only preferences.
Context dimensions
storeId selects the store and its distribution, price, supply, checkout, and rounding configuration.
priceChannelId, priceCurrency, and priceCountry participate in contextual price selection. locale selects localized content where the field supports it.
A customer access token adds customer identity and group context. Customer groups can change prices, discounts, shipping methods, and payment gateway eligibility.
Keep catalog and cart aligned
Pass the same storeId, priceChannelId, currency, and country to cartCreate that you used for the catalog. The cart then resolves its own authoritative lines, discounts, tax, shipping eligibility, and totals.
If the shopper changes market or currency, deliberately create or update the cart and re-read it. Changing only a currency formatter can display a value that cannot be checked out.
Re-query customer-sensitive catalog and cart data after sign-in or sign-out because customer-group context may have changed.
Caching and trust boundaries
Include every response-changing dimension in a public cache key: store, price channel, currency, country, locale, filters, sort, and pagination cursor. Never serve authenticated customer responses from a shared cache.
Cursors belong to their original filters, sort, and context. Discard pagination state when any of those inputs changes.
Validate store and channel identifiers against the markets your storefront supports. Do not accept arbitrary IDs from an untrusted URL and forward them directly to the API.