n-Headless Salesforce Commerce Cloud: PWA Kit and What It Actually Changes
Going headless with Commerce Cloud means separating the storefront frontend from the commerce engine running behind it, so the two only talk through the API (SCAPI) instead of Salesforce's own templated storefront rendering the page directly. Salesforce's own toolkit for this is PWA Kit: a React-based storefront starter built on the Commerce SDK for React, deployed through Salesforce's Managed Runtime hosting.
What going headless with Commerce Cloud actually involves
Commerce SDK for React. This is the data-fetching layer that wraps SCAPI calls into ready-to-use React hooks, so a headless frontend isn't writing raw API calls for every product page or cart action.
PWA Kit. Salesforce's starter storefront and CLI scaffolding built on top of that SDK, meant as the fastest path to a working headless Commerce Cloud frontend without starting from a blank React app.
Managed Runtime. The hosting and CDN layer Salesforce provides specifically for PWA Kit storefronts, since a headless frontend still needs somewhere to actually run and serve pages from.
Composable commerce. Going headless often gets paired with swapping out individual pieces of the stack, a different search provider, a separate CMS, while keeping Commerce Cloud as the underlying commerce engine, rather than replacing the whole platform.
Where headless creates new integration work, not less
Going headless doesn't remove the backend connection to Commerce Cloud, it just moves everything through API calls instead of server-rendered templates. For a business that's been running Commerce Cloud for years, this usually means the integrations built around the old storefront, order exports, inventory jobs, anything timed around how the templated store used to render or batch-process, need to be rebuilt to work with the new decoupled frontend and Managed Runtime's hosting model.
That's the part that catches people off guard. The pitch for headless is usually speed and frontend flexibility, and it delivers on that, but the ERP sync, the inventory feed, the CRM connection you already had working against the old storefront doesn't just carry over. It has to be reconnected to the new architecture on purpose.
What we've built on top of headless Commerce Cloud
Re-wiring ERP and inventory sync for a PWA Kit storefront
When a business moves from a templated Commerce Cloud storefront to a PWA Kit frontend, we rebuild the order and inventory connections that used to run against the old setup so they work against the new SCAPI-based architecture instead.
Checkout and cart events reaching your CRM or fulfillment system
A purchase or cart action on a composable frontend triggers the same downstream update, a CRM record, a fulfillment system, that the old storefront used to handle, just routed through the new architecture instead of breaking silently.
Going headless and not sure what's going to break on the backend?
Tell us what's currently connected to your Commerce Cloud storefront. We'll look at what actually needs rebuilding once the frontend goes headless, versus what keeps working as-is.
Planning a move to headless Commerce Cloud, or already stuck mid-migration?
The frontend rebuild usually gets planned for. The backend integrations that quietly assumed the old templated storefront often don't, until something stops updating. Tell us what's connected today and we'll look at what carries over cleanly and what needs rebuilding. Commerce Cloud's headless architecture is one example of this; we handle the same kind of re-wiring for any system going through a platform change.
Let's talk