Use manual setup for PWA Kit (Composable Storefront), SFRA/SiteGenesis, headless storefronts, or any storefront where you provision Managed Runtime (MRT), SLAS, and eCDN yourself.
If MRT, SLAS, and SFRA/SiteGenesis are already in place:
Link Business Manager to MRT. Connect your existing Business Manager instance to the MRT environment, then continue with the instance-type steps below.
Across all instance types, the Hybrid Auth configuration is the same: enable Hybrid Auth in Business Manager (see Shared Hybrid Auth Setup, Step 4) and set the hybrid environment variables for your Managed Runtime (MRT) or local runtime. Only the routing setup differs by environment. Configure each instance type as follows.
These instance-type steps apply to storefronts that include a headless or Managed Runtime (MRT) app (Storefront Next, PWA Kit, or a custom headless storefront). For an SFRA/SiteGenesis-only storefront, you don’t need MRT environment variables or eCDN routing—the Shared Hybrid Auth Setup is your complete configuration. See SFRA/SiteGenesis Proper + Hybrid Auth.
Use this path when maintaining or incrementally modernizing an existing SFRA or SiteGenesis storefront.
For an SFRA/SiteGenesis-only storefront, the Shared Hybrid Auth Setup is the complete instruction set—the steps below are just the SFRA/SiteGenesis-specific sequence and map to those shared steps. You don’t need the other Manual Setup sections (Fresh or Existing Setup Managed Runtime provisioning and the Set Up by Instance Type routing steps) unless you later add a headless runtime.
For an SFRA/SiteGenesis-only storefront—using Hybrid Auth for SLAS benefits such as longer sessions and federated login, without a headless runtime—the Shared Hybrid Auth Setup is your complete configuration. No headless runtime configuration or eCDN routing is required. Step 5 applies only when you start moving routes to a headless storefront.
Note
Validate the Setup
After you complete the shared setup, confirm that Hybrid Auth is working on your SFRA/SiteGenesis storefront:
Log in as a registered shopper and confirm the session persists across SFRA/SiteGenesis pages without a re-login prompt.
Confirm session extension: registered and guest sessions persist for the refresh token TTL you configured in Business Manager, rather than expiring at the default storefront session timeout.
If you configured a third-party IDP or Social Login, complete a federated login and confirm the shopper is recognized on SFRA/SiteGenesis pages.
Confirm the SLAS authorization (JWT) and the B2C Commerce session (dwsid) stay synchronized—the shopper isn’t logged out or forced to reauthenticate while browsing.
Treat this setup as a transitional state. As you modernize, adopt headless storefront components and follow the implementation guide for your target architecture:
For transitional architectures where a custom headless storefront and SFRA/SiteGenesis both serve shopper traffic.
When to Use This Path
You are in a phased migration from SFRA/SiteGenesis to a custom headless storefront.
You are not yet ready to move cart/checkout off SFRA/SiteGenesis.
This path is for headless storefronts that you build and host yourself (not Storefront Next or PWA Kit). If you use one of those frameworks, or you’re starting a greenfield implementation, follow its dedicated guide instead:
In your headless storefront, use SLAS to obtain shopper access and refresh tokens. Store them as cookies so that they’re shared with SFRA/SiteGenesis when the shopper crosses runtimes.
SLAS session-bridge token responses return cookies—including a dwsid—through the Set-Cookie header. Make sure your headless storefront applies these cookies to the shopper’s browser so that B2C Commerce and SLAS sessions stay linked across SFRA/SiteGenesis and your headless pages.
Step 3: Send the sfdc_dwsid Header on SCAPI Calls
For non-PWA Kit headless storefronts, when the dwsid cookie exists, include the sfdc_dwsid header with the dwsid cookie value on all SCAPI calls. This header keeps the shopper’s B2C Commerce session aligned with SCAPI requests from your headless runtime.
Step 4: Configure Route Ownership Between Headless and SFRA
Decide which paths your headless storefront serves and which stay on SFRA/SiteGenesis: route headless-owned paths to your headless origin, and keep the remaining paths on SFRA/SiteGenesis.
If your headless app runs on Managed Runtime (MRT), apply the split using the per-instance routing in Set Up by Instance Type: eCDN MRT routing rules via the Business Manager UI for PIG and ODS, or the local proxy for localhost.
If your headless app runs on a different origin, use your CDN’s origin-routing equivalent with the same path split.
If you added a headless or Managed Runtime (MRT) app, split routes between it and SFRA/SiteGenesis, and review the environment-specific deltas, in Hybrid Auth Environments and Routing.
For an SFRA/SiteGenesis-only storefront (no headless runtime), no eCDN routing is required—the Shared Hybrid Auth Setup is your complete configuration.