Which Headless Salesforce Approach Fits a React Frontend?

Speed

AI-narrated

If your team wants a React frontend on Salesforce, you have three headless approaches: React on Salesforce Multi-Framework, a React app hosted elsewhere that calls Salesforce APIs, or a React portal on Salesforce Sites with Apex behind it.

For employee apps, Multi-Framework is usually the strongest starting point because Salesforce hosts the app and handles sign-in. For customer and partner apps, the choice depends on who signs in, how their access is licensed, and where the app should live.

What does “headless Salesforce” mean for a React team?

Headless means the frontend is built separately from Salesforce’s own UI layer. Your React app owns the experience, and Salesforce stays the system of record for data, security and business logic.

What changed when Salesforce Multi-Framework went GA?

On July 16, 2026, Salesforce announced general availability of Salesforce Multi-Framework, a framework-agnostic runtime on the Headless 360 platform. React came first, and Winter '27 added Angular.

A Multi-Framework app is stored in your org as metadata called a UIBundle. You build it with tools like Vite, manage it in a Salesforce DX project, and deploy it like other metadata. Salesforce hosts it, so there’s no separate web server.

The Salesforce Platform SDK gives the app GraphQL reads and writes, calls to Apex methods, and user context through the UI APIs.

There is no token handling in your code. GraphQL requests from the SDK go through the User Interface API, which enforces object permissions, field-level security and sharing for the signed-in user. Apex follows its own access mode: database operations run in user mode by default in current versions, but older classes or operations set to system mode need review.

Which headless approach should you pick for a React frontend?

1. React on Salesforce Multi-Framework

Best for: employee apps, and external apps where you use or plan to use Experience Cloud.
How users get in: internal apps open from the App Launcher or the Salesforce mobile app. External apps are surfaced through an Experience Cloud site, with guest access for public pages and Experience Cloud licenses for customers and partners who sign in.
Trade-offs: it requires a Hyperforce org. Second-generation (2GP) packaging is supported for internal apps but not for external-facing apps.

2. A React app hosted elsewhere that calls Salesforce APIs

Best for: teams already running a React or Next.js app on their own hosting that need Salesforce data.
How users get in: your app handles sign-in and calls Salesforce’s GraphQL or REST APIs over OAuth.
Trade-offs: you control the stack, but you own the integration. If the app calls Salesforce as one integration user, your code has to enforce who can see what, because Salesforce only sees that one user. Check licensing too: the Salesforce Integration license is designed for system-to-system integrations, not as coverage for the people using your app.

3. A React portal on Salesforce Sites with Apex behind it

Best for: customer or partner portals where you want React and your data in Salesforce without an external database.
How users get in: the React app is served from Salesforce Sites, and Apex handles every record request.
Trade-offs: this is the approach our SF Custom Portal Template uses. Portal members are Contacts rather than Salesforce users, and their Accounts provide customer context. Access is controlled by the template’s own permission sets, applied to those Contacts and enforced in Apex on every request, so data and security stay in Salesforce. These template permission sets are separate from the native permission sets Salesforce assigns to User records. We’ve used this model on production customer portals since 2019. As with any architecture, confirm the licensing fit for your contract with your Salesforce account team.

When should you use LWC and when should you use React?

Lightning Web Components (LWC) remains the natural choice for reusable components inside Lightning pages, Experience Builder sites and the Salesforce mobile app, internal or customer-facing.

React makes sense when you want a self-contained app with a complex UI, or when your team already has React skills and a design system. A customer-facing site alone doesn’t require React. We cover the trade-offs in how LWC limits React development.

How do you start a React app on Salesforce?

Check your org. Multi-Framework needs a Hyperforce org on Summer '26 or later, in Enterprise, Performance, Unlimited, Developer or Partner Developer edition. In Setup, open Salesforce Multi-Framework Apps to confirm the Salesforce app domain is on. Internal apps also need Salesforce Edge Network enabled in My Domain.
Pick the approach based on who signs in and where the app lives.
Map your data contracts. List the queries and Apex methods each screen needs against existing permission sets.
Build a small prototype in a sandbox or scratch org and deploy it as a UIBundle.
Test permissions with real user profiles before production.

FAQ

Do external users of a Multi-Framework app need Experience Cloud licenses?

Customers and partners who sign in need appropriate Experience Cloud licenses, such as Customer Community or Partner Community. Public pages can use the site’s guest access instead.

Can I host my React app on Vercel and still use Salesforce data?

Yes, through the second approach. Your code owns sign-in and any permission checks Salesforce can’t see.

Does Multi-Framework replace LWC?

No. It runs alongside LWC, and the two serve different purposes.

Which Salesforce editions support Multi-Framework?

Enterprise, Performance, Unlimited, Developer and Partner Developer editions hosted on Hyperforce. It isn’t available in Government Cloud or Alibaba Cloud.