SCAPI vs SFRA: Choosing the Right Salesforce Commerce Cloud Architecture
The framing of this question often presupposes that one architecture is modern and the other is not. That framing is wrong, and making this decision based on it produces outcomes that reflect the framing rather than the requirements.
The Wrong Way to Frame This Decision
The most common framing of the SCAPI versus SFRA question presents it as a timeline: SFRA is the established way, SCAPI with PWA Kit is the direction of the platform, and choosing SCAPI means choosing the future. This framing is actively harmful because it short-circuits the actual decision-making process and introduces a technology identity component into what should be a requirements-driven engineering decision.
SFRA — the Storefront Reference Architecture — is Salesforce’s current, actively maintained, production-proven server-rendered commerce architecture. SCAPI — the Commerce API, accessed via a React storefront typically built on PWA Kit — is Salesforce’s headless architecture pathway. Both are current. Both are supported. Both are the right choice in different contexts.
The architecture decision should be made on the basis of which approach solves your specific requirements given your team’s capabilities and your commercial constraints. This article provides the information required to make that decision.
What SFRA Actually Is
SFRA is a controller-and-template architecture. Page requests are handled by SFCC controllers — JavaScript files that execute server-side — which interact with the SFCC platform via its scripting APIs and render responses using ISML templates, SFCC’s server-side templating language. The rendered HTML is delivered to the browser.
SFRA is extended through cartridges: discrete packages of controllers, templates, scripts, and static assets that extend or override the reference architecture without modifying it directly. This overlay system allows platform upgrades and site customizations to coexist when implemented correctly, which is the primary reason SFRA implementations maintain upgrade paths that heavily-modified legacy SiteGenesis implementations could not.
The SFCC ecosystem has built a substantial library of SFRA-compatible cartridges: payment processor integrations for Adyen, Cybersource, Stripe, and Braintree; loyalty program connectors; review and UGC platforms; tax services; inventory feed integrations. This ecosystem exists because SFRA has been the dominant SFCC architecture long enough for third-party developers to build against it. It represents a practical advantage in implementation speed that is frequently underweighted in architecture evaluations.
What SCAPI Actually Is
SCAPI is the Commerce API — a set of RESTful APIs that expose SFCC’s core commerce functions as endpoints callable from any client. The Shopper API suite covers the full commerce journey: product browsing via ShopperProducts and ShopperSearch, basket management via ShopperBaskets, checkout via ShopperOrders, and authentication and account management via ShopperLogin and ShopperCustomers.
SCAPI does not replace SFCC’s back-end. Products, pricing, promotions, inventory, and order management remain in SFCC. SCAPI is the interface through which an external application communicates with that back-end.
PWA Kit is Salesforce’s React-based storefront framework designed to work with SCAPI. It is not the only way to build a SCAPI storefront — custom React applications built against SCAPI without PWA Kit are a valid approach — but it is the reference path with the most direct Salesforce support. PWA Kit runs on Managed Runtime, Salesforce’s Node.js hosting environment.
The Feature Coverage Gap
This is where the architecture decision has a significant practical dimension that is not always surfaced in evaluation conversations.
SFRA exposes the full SFCC feature set natively. If SFCC supports it — complex promotion stacking, price books, customer groups, Page Designer, Einstein Recommendations — SFRA can implement it because the controller has direct access to the platform’s scripting API.
SCAPI exposes a curated subset of SFCC functionality as REST endpoints. The coverage is substantial and sufficient for most B2C commerce scenarios. However, there are features available in SFCC that are not exposed through SCAPI endpoints, and there are features that require specific implementation approaches in SCAPI that are native in SFRA.
Before committing to a SCAPI-based architecture, validate that every feature on your commerce requirements list has confirmed SCAPI support in the current release. This validation should be done against current API documentation, not against general statements about SCAPI capability. The coverage gap is smaller than it was three years ago, but it is not zero, and discovering a gap mid-implementation is expensive.
Page Designer: The Operational Difference That Has the Widest Impact
Page Designer is where the SFRA versus SCAPI choice has the most visible operational impact, and it is consistently underweighted in technical architecture discussions because it is perceived as a merchandising concern rather than an engineering one.
In SFRA, Page Designer works natively. Content managers build and publish pages — homepage layouts, landing pages, promotional content — through a visual editor in Business Manager. Published content renders immediately on the storefront. The feedback loop between content management and storefront output is immediate.
In a SCAPI implementation, Page Designer operates via Headless Page Designer: a set of APIs that return Page Designer content as structured JSON representing the component tree. The storefront fetches this JSON and renders it using React components that correspond to each Page Designer component type.
For this to work in production, every Page Designer component must have a corresponding React implementation in the PWA Kit codebase. Out-of-the-box SFCC components have reference React implementations available in the PWA Kit SDK. Custom components — those developed for your specific implementation — require custom React development for each.
The ongoing operational implication: if the merchandising team creates a new Page Designer component type that does not have a React implementation, it does not appear on the storefront. This creates a coordination requirement between the engineering team and the commerce operations team that does not exist in SFRA and that must be operationalised with a clear process for how new component requests are handled, prioritized, and delivered.
This is manageable. The organisations for which it creates the most friction are those where the merchandising team operates with a high degree of independence, frequently creates new content component types, and has a low tolerance for waiting on engineering resource to enable new content capabilities.
Einstein Recommendations: The Implementation Difference
Einstein Recommendations in SFRA is implemented through the Einstein cartridge: zones are configured in Business Manager, placed on templates, and the cartridge handles API calls and rendering. For most SFRA implementations, Einstein is operational within a standard cartridge integration engagement.
In SCAPI, Einstein Recommendations uses the API endpoints directly. You make explicit calls to the recommender endpoints, passing product context and shopper activity identifiers, and render results in React components. The outcomes are equivalent; the implementation path is explicit rather than cartridge-abstracted.
The critical consideration — and the one most commonly responsible for degraded recommendation quality post-go-live — is activity tracking. Einstein’s models are trained on shopper activity data: product views, add-to-cart events, purchases. In SFRA, the Einstein cartridge handles tracking. In SCAPI, you implement tracking calls explicitly at the appropriate points in the shopper journey. Missing or misconfigured tracking degrades recommendation quality progressively over the weeks following go-live — subtle enough to not always be caught during UAT, material enough to affect revenue for recommendations-dependent merchandising strategies.
Performance: The Honest Comparison
The performance advantage of SCAPI and PWA Kit is real, but it requires qualification to be useful.
PWA Kit with SSR enabled on Managed Runtime, ISR configured for product listing and content pages, and a properly constructed JavaScript bundle will achieve Core Web Vitals scores that are structurally difficult to reach with SFRA at equivalent engineering effort. The combination of React’s component model, server-side rendering, and ISR-based edge caching provides a performance architecture that SFRA’s server-rendering model does not natively replicate.
However, SFRA with proper optimization — JavaScript bundle splitting, critical CSS extraction, strategic lazy loading, optimized image delivery pipelines, and SFCC’s caching layer correctly configured at the page, fragment, and data levels — can achieve Lighthouse scores in the 80s and 90s on mobile. The performance gap between optimized SFRA and a well-implemented PWA Kit storefront is smaller than the marketing narrative suggests.
The inverse is equally true and equally important: a PWA Kit implementation without performance engineering — an unbounded JavaScript bundle, client-side-only rendering for above-the-fold content, unconfigured ISR, unmanaged third-party script loading — will perform worse than SFRA. The framework provides the architecture for performance; the implementation delivers it.
If Core Web Vitals performance is a primary driver in your architecture decision, conduct a rigorous performance audit of your current SFRA implementation before assuming that architecture change is the solution. In many cases, it is not.
B2B Commerce Cloud: A Different Default Answer
For Salesforce B2B Commerce Cloud implementations, the SCAPI versus SFRA question has a different default answer and it is one that surprises teams that approach B2B with the same framing as B2C.
B2B Commerce Cloud remains primarily SFRA-based in its current form. The composable storefront architecture for B2B — SCAPI-based headless — is less mature than the B2C equivalent. B2B-specific features — account hierarchies, contract pricing, quote management, approval workflows, punch-out integrations — have limited SCAPI coverage compared to B2C Commerce Cloud.
For most B2B implementations, SFRA is the architecturally sound current choice. Validate the SCAPI coverage for your specific B2B requirements against the current platform release before proceeding with a headless approach for B2B scenarios.
Team Capability: The Variable That Determines the Outcome
The most consequential variable in this decision is frequently the least discussed in formal architecture evaluations: the capability profile of the team that will build and maintain the implementation.
SFRA development requires familiarity with SFCC’s controller and cartridge model, ISML templating, Business Manager configuration, and the SFCC scripting API. This skill set is SFCC-specific, available within the SFCC implementation ecosystem, and learnable with a clear progression path.
PWA Kit development requires React expertise, understanding of SSR and ISR patterns, Node.js familiarity, and SFCC-specific knowledge of SCAPI, SLAS, the Managed Runtime environment, and Headless Page Designer. This is a broader, more composite skill set. The React ecosystem talent pool is larger than the SFRA talent pool, but SFCC-specific React experience — specifically SCAPI, SLAS configuration, and PWA Kit — is still relatively uncommon, and general React expertise does not substitute for it in implementation.
An SFRA project delivered by a team with four or more years of SFCC experience will consistently outperform a PWA Kit project delivered by a team with strong React skills but limited SCAPI experience. The architecture does not compensate for knowledge gaps; it amplifies them. Every SFCC-specific behavior — promotion engine resolution, pricing stack, basket service nuances, the SLAS token lifecycle — needs to be understood regardless of which storefront architecture is on top of it, and that understanding takes time to develop.
If your implementation team is new to SFCC, SFRA is typically the lower-risk starting point. The platform behaviors are learned within a familiar architectural pattern. PWA Kit adds SCAPI, SLAS, and Managed Runtime on top of this foundation, and developing platform fluency and framework fluency simultaneously extends the ramp-up period materially.
The Decision Matrix
Choose SFRA when:
The implementation team’s primary SFCC experience is SFRA-based and there is no specific architectural requirement that headless solves for your project.
Page Designer is a primary content management tool and your merchandising team operates with high independence and frequency.
The implementation timeline and budget are fixed and the risk profile of a headless implementation — longer ramp-up, SLAS complexity, Headless Page Designer coordination — cannot be absorbed within those constraints.
The implementation is B2B Commerce Cloud.
Your requirements include SFCC features with limited or unconfirmed SCAPI coverage in the current release.
The cartridge ecosystem provides integrations that would require custom development in a SCAPI implementation.
Choose SCAPI with PWA Kit when:
A React-based design system already exists that the SFCC storefront needs to share, and maintaining a parallel SFRA component library is not architecturally acceptable.
The storefront needs to integrate with a headless CMS, external content platform, or APIs that benefit from a JavaScript rendering layer in ways that would require significant workarounds in SFRA.
The implementation team has direct SCAPI and PWA Kit experience, or the project timeline includes a realistic ramp-up period with appropriate support.
Core Web Vitals performance is a primary commercial requirement and the storefront cannot achieve target scores on SFRA with reasonable optimization effort — validated by an actual performance audit, not assumed.
The organisation is building toward a composable commerce architecture where the storefront layer is explicitly designed to be replaced or augmented independently over time.
Consider SFRA now with a planned SCAPI migration when:
The business case for headless is valid but the team does not yet have the SCAPI experience to execute it well. Implement SFRA to meet the current commercial timeline, invest in SCAPI familiarity through API-first integration work, and plan the headless migration for a subsequent phase with a team that can execute the architecture properly. This sequence produces better outcomes than a headless implementation rushed to meet a deadline with an underprepared team.
Architecture Is an Engineering Decision, Not an Identity Statement
The SCAPI versus SFRA decision should be a pragmatic, requirements-driven engineering choice. Both architectures produce successful production implementations. Both produce failed ones. The architecture is not the variable that determines the outcome; the quality of the implementation is.
The right answer for your platform depends on what you are building, who is building it, and what constraints you are operating within. When those variables are clearly defined, the architecture choice follows from them. When they are not, the architecture choice precedes the requirements — which is how the wrong architecture gets selected for the right reasons.
Coredevex works across both SFRA and SCAPI architectures on Salesforce Commerce Cloud. If you are at the point in a platform evaluation or implementation planning process where the architecture decision needs to be made from informed analysis rather than vendor narrative, We work exclusively with Salesforce Commerce Cloud — both architectures, in production.