How Do You Design Shared Contracts for Headless Salesforce Apps?

A React app, an Angular app and a Lightning page can use the same Salesforce records without sharing a frontend codebase. The harder question is what they should share: business rules, authorization, data contracts and responsibility when something changes.

This guide focuses on those contracts across multiple apps. It complements the broader headless Salesforce architecture overview, rather than treating every new surface as a reason to rebuild the backend.

What should stay shared across frameworks?

Keep business decisions out of individual screens where possible. A status transition, eligibility check or approval requirement shouldn’t mean one thing in React and another in Angular.

Define the operation once in the appropriate Salesforce service, then expose a narrow contract. A useful contract records:

• Inputs and validation rules.
• The execution identity and required access.
• Returned fields and possible error outcomes.
• Whether the operation changes records.
• The owner responsible for compatibility and support.

Sharing a contract doesn’t mean giving every app the same permissions. Two apps can call the same operation with different users and receive different permitted results.

Where can the apps run today?

Salesforce Multi-Framework supports React and Angular apps hosted on Salesforce as UI bundles. Internal apps use Salesforce credentials and open from the App Launcher or mobile app. External apps use Experience Cloud sites, with public guest access or appropriately licensed signed-in users.

The runtime requires Hyperforce and Summer '26 or later in supported editions. Its setup guide excludes Government Cloud and Alibaba Cloud. Don’t extend those requirements into a claim that all headless Salesforce architectures require Hyperforce: an externally hosted frontend calling Salesforce APIs is a different pattern.

Likewise, a Multi-Framework app isn’t an LWR page assembled in Experience Builder. Its external template includes site metadata, but Salesforce says its site can’t be edited in Experience Builder.

Which data logic can be reused without coupling the UIs?

Use GraphQL for supported record operations through the Data SDK, and Apex or Flow-backed services for business operations that need controlled sequencing. Keep frontend state and styling local to each app.

Winter '27 adds Data SDK extensions: reusable data logic defined once and attached to SDK instances. This can reduce repeated query code across bundles. It doesn’t turn a shared extension into a server-side authorization boundary.

For example, an account list and a service dashboard might share a query helper but use different layouts. A case-escalation operation should enforce its rules on the server rather than trusting a disabled button in either UI.

Avoid returning a large generic record payload just because several apps might need it later. Define the fields each operation actually requires, along with pagination and understandable errors.

How do you keep permissions consistent?

Data SDK GraphQL requests flow through the User Interface API, which enforces object permissions, field-level security and record sharing. Custom Apex needs its own review of execution and database access modes. User-mode operations respect the running user’s permissions; explicit system-mode operations and older API-version code need particular attention.

For an external app using one integration identity, Salesforce sees that identity, not every person using the frontend. Any required end-user authorization belongs in trusted server-side logic, not browser checks. Confirm that the selected license and API access fit the intended use.

Write down that identity mapping for each surface before claiming they all share one security model.

What changes when you compose apps inside a page?

Running standalone apps and embedding them are separate decisions. Embedding an internal Multi-Framework UIBundle in a Lightning or Experience Cloud page is Beta. A thin LWC renders lightning-ui-embedding, pointing at the app’s salesforce.app URL. The app runs inside a sandboxed iframe.

Define the host contract as carefully as the data contract: which context enters the app, which events leave it and what the page shows when loading fails. Don’t pass secrets in page events, and don’t assume the frame can access the host page’s session cookies or DOM.

The Micro-Frontends pattern provides composition, not shared React state or automatic compatibility between independently released apps.

How do you change shared contracts safely?

Treat each consumer as a dependency when changing a field, validation rule or service response. Prefer additive changes, test current consumers and agree how an old contract will be retired before removing it.

Maintain a simple register: operation, owner, consumers, required permissions and last compatibility test. Include failure and restricted-access cases, not only successful responses. Test a service change against every app that uses it before release.

Packaging also affects the plan. Winter '27 supports 2GP for internal Multi-Framework apps; external-facing app packaging is unsupported. Don’t confuse that support with a promise that every dependency can be upgraded independently without testing.

FAQ

Can React and Angular share a backend?

Yes. They can consume the same supported Salesforce APIs and business services while keeping separate UI implementations.

Do shared SDK extensions enforce access control?

No. They’re reusable client-side data logic. Authorization must still be enforced by the server operations they call.

Does an iframe automatically share the host’s login cookies?

No. Multi-Framework apps have origin isolation and scoped sessions. Use documented SDK and embedding interfaces rather than reading host storage.

Should every screen become a separate app?

No. Split where ownership, release needs or UI requirements justify it. Each split creates another contract and failure state to maintain.

Sources: Multi-Framework overview, project structure, embedding (Beta), Winter '27 guide, Apex access modes.

Book an intro call below.