What SFCC’s Headless Architecture Actually Means in Production
The gap between what Salesforce says headless is and what it looks like twelve months into a live implementation is significant. This is the production version.
The Architecture Nobody Draws Accurately
Every diagram of SFCC headless shows the same simplified picture: a React frontend on one side, SFCC on the other, and an arrow labelled “API” connecting them. The diagram is accurate in the same way a subway map is accurate — it captures the essential relationship while leaving out most of what is actually there.
In production, a headless Salesforce Commerce Cloud implementation involves at minimum five distinct layers: the storefront application (typically built on PWA Kit), the Managed Runtime hosting environment, the Commerce API (SCAPI) layer, the SFCC back-end covering products, pricing, promotions, and order management, and the Shopper Login and API Access Service (SLAS) that handles authentication across all of it. Each layer has its own configuration surface, its own failure modes, and its own operational overhead.
What follows is an accurate description of what headless on SFCC actually involves — not from the implementation guide, but from production.
What “Headless” Specifically Means on SFCC
Headless commerce, in the Salesforce context, means decoupling the storefront presentation layer from the SFCC back-end using the Commerce API. The storefront no longer runs SFRA controllers or pipelines. It does not render pages server-side via SFCC’s rendering engine. Instead, a separate application — built in React, typically using Salesforce’s PWA Kit as the starting framework — makes authenticated API calls to SCAPI endpoints and renders the result via server-side rendering on Managed Runtime or in the browser.
This is categorically different from what “headless” means in the context of platforms like Commercetools or Elastic Path, where headlessness is the default architecture. SFCC was built as a traditional, server-rendered platform. Headless was introduced as an alternative path, not the native one. That distinction matters in practice, because it means some platform features — those built into the SFRA rendering engine — work differently, or require separate integration work, in a headless implementation.
Managed Runtime: The Dependency That Changes Everything
PWA Kit storefronts are hosted on Managed Runtime (MRT) — Salesforce’s Node.js hosting environment, originally built by Mobify before the acquisition. This is a point that gets insufficient attention in early scoping conversations, and it has material implications for architecture, performance, and operations.
Managed Runtime is not optional for PWA Kit. You can deploy a custom React application built against SCAPI to your own infrastructure, but if you are using PWA Kit, you are on Managed Runtime.
In production, MRT gives you server-side rendering, edge caching, and automated scaling. It handles the Node.js runtime, deployment pipeline, and CDN configuration. In exchange, your storefront’s hosting is a platform dependency rather than something your infrastructure team controls directly. For most enterprise brands this is acceptable. For those with specific data residency requirements, existing CDN contracts, or strict infrastructure governance, it requires a conversation in the architecture phase — not after go-live.
PWA Kit v3 introduced Incremental Static Regeneration (ISR), borrowed from the Next.js model. This is architecturally significant: product listing pages and content-heavy pages can be statically generated and served from the CDN edge, revalidating in the background rather than rendering on every request. The performance implications are substantial. Getting cache invalidation right for price changes, inventory updates, and promotional content is equally substantial and should not be underestimated in project planning.
SLAS: The Authentication Layer That Requires Explicit Engineering
The Shopper Login and API Access Service is the authentication infrastructure for SCAPI. It handles guest shopper tokens, registered customer authentication via OAuth 2.0 PKCE flow, and token refresh. In a well-configured production implementation it is invisible to the shopper. Getting it there takes longer than most project plans allow for.
Every SCAPI call requires a valid access token issued by SLAS. Guest shoppers receive a short-lived access token and a longer-lived refresh token. The storefront is responsible for token lifecycle management: storing tokens appropriately in httpOnly cookies rather than localStorage for security reasons, silently refreshing the access token before expiry, and handling the edge cases where a refresh fails.
The silent refresh pattern — where the storefront detects an expiring token and requests a new one using the refresh token without interrupting the session — requires careful implementation. Production edge cases include browser tabs inactive long enough for the refresh token to expire, network failures during the refresh call, and concurrent requests that all trigger a refresh simultaneously. Each requires explicit handling.
For brands migrating from SFRA, there is an additional complexity: the Session Bridge. Existing registered customers have sessions managed by SFCC’s server-side session system. If you are running a headless storefront alongside an existing SFRA storefront or migrating existing customer sessions, the Session Bridge component allows SLAS tokens to be exchanged for SFCC server sessions. This is used primarily in hybrid migration scenarios and requires explicit configuration on both the SLAS and SFCC back-end sides.
What Works Differently in Headless
Page Designer
SFCC’s Page Designer is built into the SFRA rendering engine. In a traditional SFRA implementation, content managers build and publish pages through Page Designer and they appear immediately on the storefront. In headless, this integration does not exist natively.
Salesforce’s solution is Headless Page Designer: a set of APIs that expose Page Designer content as structured JSON, which the React storefront fetches and renders using matching component implementations. The merchant experience in Page Designer is preserved; the storefront renders the component tree from the API response rather than from SFCC’s server-side engine.
The practical implications: every Page Designer component must have a corresponding React component in the PWA Kit implementation. Out-of-the-box SFCC Page Designer components — carousels, product grids, banners — need React equivalents built or sourced. Custom components added by merchandisers that do not have a React counterpart will not render on the storefront.
This creates an ongoing coordination requirement between the engineering team and the commerce operations team that does not exist in SFRA. Teams where merchandising operates with high autonomy and frequently creates new Page Designer component types will find this the most friction-generating aspect of a headless implementation.
Einstein Product Recommendations
Einstein Recommendations in headless uses SCAPI’s Einstein API endpoints. The integration works, but it is not the same as SFRA’s native Einstein integration where recommender zones are configured in Business Manager and rendered server-side via the Einstein cartridge. In headless, you make explicit API calls to the recommender endpoints, pass the appropriate context — user activity events, product identifiers — and render the results in React components.
The activity tracking that feeds Einstein’s models must also be implemented explicitly in headless. In SFRA, the Einstein cartridge handles this. In PWA Kit, you instrument the tracking calls directly at the appropriate points in the shopper journey. Misconfigured or missing activity tracking degrades recommendation quality progressively over time — a problem that is not always visible in UAT and may not surface until weeks after go-live.
B2B Commerce
If your implementation is B2B Commerce Cloud rather than B2C, the headless architecture question requires a different analysis. As of current platform releases, B2B Commerce Cloud remains primarily SFRA-based. SCAPI coverage for B2B Commerce — account hierarchies, contract pricing, quote management, approval workflows — is more limited than for B2C. Validate the SCAPI coverage for your specific B2B requirements against current documentation before committing to a headless approach.
The Performance Reality
The performance case for headless on SFCC is real but not automatic. A PWA Kit storefront with SSR enabled on Managed Runtime, ISR configured for catalogue and content pages, and a properly optimized JavaScript bundle will outperform a typical SFRA storefront on Core Web Vitals. That is the ceiling case.
The floor case — a PWA Kit implementation with an unbounded JavaScript bundle, client-side-only rendering for above-the-fold content, and unconfigured third-party script loading — will perform worse than SFRA. The framework provides the architecture for performance; the implementation delivers it. This is worth stating directly because headless is frequently positioned as a performance solution when it is more accurately a performance opportunity that requires execution to realise.
When Headless Is the Right Architecture
Design system ownership. The engineering team has an existing React design system that the SFCC storefront needs to share. Building in SFRA means maintaining a parallel component library. PWA Kit allows the same components to be used across products.
Composable architecture. The storefront needs to integrate with a headless CMS, separate PIM, or content services outside the SFCC ecosystem in ways that benefit from a JavaScript rendering layer.
Performance at scale. With ISR and proper bundle optimization, PWA Kit storefronts can achieve Core Web Vitals scores that are structurally difficult to reach on SFRA at equivalent effort. For high-traffic, conversion-sensitive storefronts, this is commercially significant.
Developer experience and talent strategy. The React ecosystem offers tooling, testing frameworks, and a talent pool that the SFRA cartridge model cannot match. For organisations building a long-term engineering capability around their commerce platform, this has genuine organisational value.
When Headless Is Not the Right Architecture
When the primary driver is “being modern.” Headless introduces genuine operational complexity. If the motivation is positioning rather than a specific technical or commercial problem it solves, that complexity has no corresponding benefit.
When the merchandising team is the primary storefront operator. Page Designer in headless works, but it requires more development overhead to maintain than SFRA’s native integration.
When the timeline is fixed and the budget is constrained. Headless SFCC implementations take longer and require more experienced teams than SFRA implementations of equivalent scope.
When the implementation team has limited SCAPI experience. SLAS configuration, token management, ISR setup, and Headless Page Designer integration all require specific expertise. A team whose SFCC experience is primarily SFRA-based will produce an implementation that looks headless but performs like neither architecture at its best.
The Production Conclusion
Headless on SFCC is a viable, production-proven architecture with specific advantages for specific scenarios. It is not a universal improvement over SFRA, and the standard description of it — fast, modern, flexible — is accurate only to the extent that the implementation delivers on each of those properties individually. Each requires explicit work.
The questions to answer before committing to the architecture: which specific platform constraints does headlessness solve for you; does your team have direct SCAPI and SLAS experience; what is your Page Designer dependency; and what is the operational model for maintaining the React component library over the product lifecycle?
The right architecture is the one that solves your actual problems with the resources you actually have.
If you are evaluating headless architecture for your Salesforce Commerce Cloud platform, or working through an existing headless implementation that is not performing as expected, — across both SFRA and SCAPI.