Headless Salesforce Commerce Cloud: What It Actually Means for Your Frontend

"Headless SFCC" gets treated in RFPs and architecture docs like a single switch: on or off. In practice, the term describes which API layer your frontend talks to and how much rendering logic still lives inside Salesforce. That is not a yes-or-no question, it is a set of architecture decisions. This post explains what headless actually means on SFCC before you get anywhere near picking a frontend to build it with.

Where SFCC starts from

Salesforce Commerce Cloud ships with the Storefront Reference Architecture (SFRA): a server-rendered storefront template built on Node.js and ISML templates, running directly inside the Commerce Cloud instance. SFRA is not an add-on, it is the default delivery path that most SFCC implementations were originally built on. Rendering, business logic, and backend sit on the same platform here.

Going headless means pulling rendering out of that picture. Instead of the platform delivering HTML, it delivers data through an API, and a separate frontend renders the page. That reframes the decision from "SFRA or headless" to which API layer the decoupled frontend uses, and how much of the existing SFRA logic has to move with it.

The two API layers that actually matter

OCAPI (Open Commerce API) is SFCC's older REST API. It covers shopping and data endpoints and was, for a long time, the only way to talk to SFCC without SFRA rendering. OCAPI is functional but was not designed for modern headless frontends: versioning, rate limits, and endpoint structure still follow SFRA-era thinking.

SCAPI (Salesforce Commerce API) is the current API generation and the path Salesforce recommends for new headless projects. SCAPI is built more granularly, supports Custom APIs for your own business logic, and is the foundation Salesforce's own PWA Kit runs on. Anyone planning a headless setup on SFCC today builds on SCAPI, not OCAPI, because OCAPI is being phased down and was never designed to carry new custom endpoints.

This distinction is the first place "headless SFCC" becomes concrete: it is not a single state, it is an API choice with direct consequences for maintainability and future-proofing.

Three ways to go headless on SFCC

1. Keep SFRA, but stop treating it as pure server-side rendering. Some teams keep SFRA for parts of the logic (checkout flows, promotions) and only decouple specific frontend areas. This is rarely a clean target architecture, but it is a common real-world midpoint during migration.

2. PWA Kit. Salesforce's own React-based storefront toolkit, built directly on SCAPI and hosted on the Managed Runtime. PWA Kit removes a lot of integration work but ties you to Salesforce's rendering and hosting model. For teams that want to move off SFRA quickly without building a frontend from scratch, this is the obvious first step.

3. A fully decoupled frontend. A standalone frontend that talks to SFCC exclusively through SCAPI (plus custom APIs where needed), hosted and rendered independently of PWA Kit or SFRA. This is the path with the most control over rendering strategy, performance, and composable integrations, and also the one with the most integration work on your side.

Judging which of these three paths fits your case is deliberately not the subject of this post. That call depends heavily on existing custom code, team capacity, and timeline. For a full breakdown, see our comparison Salesforce Commerce Cloud Frontend Options: SFRA, PWA Kit, Storefront Next, or an FMP Decouple, and for PWA Kit specifically, our PWA Kit Alternatives buyer guide.

What stays on the backend in every headless SFCC setup

No matter which path you choose, certain responsibilities stay with SFCC:

• Product catalog and pricing logic. Catalog structure, price books, and promotion rules are still configured in Business Manager and delivered through SCAPI, not rebuilt in the frontend.
• Order management and checkout core logic. Order processing, payment integrations, and order status run through SFCC backend processes, even when the checkout UI lives in the decoupled frontend.
• Search and recommendations (Einstein). Where Einstein Search/Recommendations is in use, the search and recommendation logic stays server-side; the frontend just consumes the results through the API.
• Page Designer content blocks, if still in use, are delivered through the API and need to be rebuilt inside the decoupled frontend, not embedded via iframe.

That means headless on SFCC is never "replace the backend." It is a decision about where the rendering boundary sits, not about whether SFCC remains your commerce engine.

The decisions that actually come up

When you plan headless SFCC, these are the real forks in the road, not "which frontend framework":

1. API foundation: SCAPI as the target state, OCAPI reserved for legacy integrations that have not been migrated yet.
2. Rendering ownership: use PWA Kit and Salesforce's Managed Runtime, or control rendering and hosting entirely yourself.
3. Content model: keep Page Designer as the content source and deliver it via API, or move content composition into a standalone frontend layer.
4. Migration path: a big-bang cutover away from SFRA, or an incremental decoupling of individual page areas while the store stays live.

These four points determine how much architectural freedom you end up with, and how much integration effort lands on your team. If you're also weighing how the operating model behind this fits together, see our post on Frontend as a Service for Salesforce Commerce Cloud Explained.

Where Laioutr fits into this picture

As a composable headless frontend layer, Laioutr connects directly to SCAPI and takes over rendering ownership entirely, without requiring you to rebuild content and commerce logic inside SFCC. That maps to the third path above: a decoupled frontend, without carrying all the integration work yourself. For SFCC teams, that means Business Manager, pricing logic, and order management stay unchanged in Salesforce, while layout, campaign composition, and editing happen directly in the visual editor, not in the dev backlog.

Frequently asked questions

Is OCAPI still an option for new SFCC projects? For existing integrations, yes. For new custom endpoints, no longer a sound choice. Salesforce builds all new functionality on SCAPI, so new projects should default there.

Do I have to use PWA Kit to go headless? No. PWA Kit is one of several options, not a requirement for headless operation. A fully decoupled frontend can talk directly to SCAPI, independent of PWA Kit and the Managed Runtime.

Does this make SFCC redundant? No. Catalog, pricing logic, promotions, and order management stay SFCC's responsibility. Headless changes where rendering happens, not who runs the commerce logic.

Next steps

If you're deciding what your headless SFCC setup should look like, book a 30-minute demo and we'll show you what a SCAPI-native frontend without PWA Kit lock-in actually looks like.

More from the Laioutr Platform

• Headless Frontend for Salesforce Commerce Cloud
• Composable Headless Frontend at Laioutr
• Agentic Frontend Management Platform

About the author: Marcel Thiesies is Co-Founder of Laioutr and spends his days on how commerce teams protect their backend investment while modernizing the frontend.