Headless 360 in Salesforce: Building a Decoupled Customer Platform with APIs

Salesforce is no longer just a UI-driven platform. In 2026, every major Salesforce cloud exposes APIs that let you decouple the frontend from the backend — building a "headless" Customer 360 where custom frontends (React, mobile, IoT, kiosks, wearables) consume Salesforce data and capabilities via APIs. As the Salesforce Platform architect documentation confirms, the platform is explicitly designed to be "open and interoperable" — providing APIs, tools, and integration standards for external systems to integrate. This post maps the entire headless surface area across Data Cloud, Commerce, Identity, and CRM, and shows how to compose these APIs into a complete decoupled customer platform.

Section 1: What Does "Headless" Mean in Salesforce?

In a traditional Salesforce implementation, the UI, logic, and data all live on one platform. Lightning pages render inside Salesforce, Flows execute inside Salesforce, and LWC components run inside the Experience Cloud or Lightning app context. The frontend and backend are tightly coupled by design — you get a fully opinionated stack that is fast to configure but limited in how far you can customise the consumer experience.

Headless means decoupling the frontend entirely. Salesforce becomes the backend engine — handling data, logic, security, and AI — while a custom application built on any framework consumes Salesforce capabilities via APIs. The concept is familiar from headless CMS and headless commerce, but the scope in Salesforce in 2026 is far broader. As Trailhead's headless architecture module explains, headless means "being able to interact with shoppers on multiple touchpoints using APIs" — and that principle applies equally to Service Cloud, Data Cloud, Identity, and CRM.

The Salesforce Platform itself reflects this shift. Architect.salesforce.com confirms that Data 360 features a "headless Semantic Layer with APIs" designed to enhance business semantics and AI/ML-driven analytics. The platform has evolved from a monolithic architecture to a structure with independent services, making the headless pattern a natural fit for the direction Salesforce is travelling.

The key principle is simple: Salesforce handles data, logic, security, and AI. You handle the UX.

Section 2: The Headless API Surface — What Salesforce Exposes

The headless surface area across Salesforce is broader than most architects realise. Across Data Cloud, Commerce, Identity, and core CRM, there are distinct API families each designed for a specific class of integration. Understanding all of them is the prerequisite for composing a complete headless Customer 360.

Data Cloud APIs

The Data Cloud Connect REST API lets you build custom solutions on top of Data Cloud. According to the developer documentation, its key capabilities include querying customer profile information, calculated insights, identity resolution rulesets, and segments; creating, updating, and running calculated insights; and managing segments and identity resolution rulesets. The individual API resources within this family serve distinct use cases:

Commerce APIs

The Salesforce Commerce API (SCAPI) is the headless backbone for Commerce Cloud. It exposes two categories: Shopper APIs (product browsing, cart, checkout, promotions, inventory, shipping, and billing) and Admin APIs (product management, orders, and inventory operations). SCAPI also supports hooks — custom endpoints that let you extend or override built-in behaviour for specific use cases.

The Composable Storefront is Salesforce's official headless commerce solution, consisting of the PWA Kit (React.js framework) plus Managed Runtime (MRT), a serverless hosting environment. According to Salesforce's headless commerce page, the platform has delivered 99.99% historical uptime and handled over 10 billion API calls over Cyber Week — evidence of the scale at which SCAPI operates in production.

Headless Identity APIs

Salesforce Headless Identity separates back-end authentication from front-end identity experiences. Three APIs are available: the Headless Login API, the Headless Registration API, and the Headless Forgot Password API. You can also link an SSO provider to create a native SSO experience in a custom app. Because these APIs are exposed through Experience Cloud, a lightweight Experience Cloud site must be set up as part of the configuration — though your users never interact with it directly.

CRM REST APIs

The core CRM REST API family provides the standard building blocks: sObject, composite, and batch operations for querying, creating, and updating records; the Connect REST API for broader platform resources including Chatter, Knowledge, and approvals; the Tooling API for metadata operations; the Streaming API and Platform Events for real-time event subscriptions; and the GraphQL API (now generally available) for flexible querying with field selection.

Section 3: Headless Data Cloud — The API-First Customer 360

Data Cloud is the foundation of headless Customer 360 in Salesforce. Unified profiles, segments, and calculated insights are all available via the Data Cloud Connect REST API, which enables custom applications to query or activate profiles in real-time during customer interactions. The architect.salesforce.com integration patterns guide confirms two specific on-demand API-based activation patterns: custom application integration via Connect API, and complete customer profile retrieval via the Data Graph API.

The Data Graph API is particularly powerful for composite applications. It returns a pre-joined, real-time JSON representation of a customer's full 360° view — reducing the number of API calls an application must make to assemble a complete profile. Instead of calling Profile API, then Calculated Insights API, then querying related DMOs separately, the Data Graph API pre-joins related DMOs into a single response. According to the architect integration patterns, this is the recommended pattern for "complete customer profile retrieval for decisioning or personalisation."

The Segment Members API — introduced in API v58.0 — lets external systems check segment membership directly. A GET /ssot/segments/{segmentApiName}/members request returns segment members with support for filters, limits, and sort order. This means external systems can check whether a customer belongs to a segment without replicating segment data outside Salesforce.

For external analytics and data science workloads, the zero-copy outbound pattern allows external systems such as Databricks, Snowflake, and Tableau to access enriched segments and insights in Data Cloud without data replication. The external system accesses the data in place; no copy is created and no data movement occurs.

Section 4: Headless Commerce — Composable Storefronts

Salesforce Composable Storefront is Salesforce's official headless commerce solution, launched in 2021. It consists of two primary components: the PWA Kit, an open-source framework for building storefronts with JavaScript and React.js; and Managed Runtime (MRT), a serverless, highly scalable hosting environment. Together, they provide a complete headless stack that communicates with B2C Commerce exclusively through SCAPI.

According to the developer documentation, the PWA Kit app runs on top of MRT, which uses SCAPI to interact with all Commerce features: products, catalogs, shopper baskets, promotions, inventory, shipping, and billing. The CDN layer supports stacking the embedded CDN (eCDN) and additional CDN providers, enabling edge-level routing, caching, and response optimisation for global storefronts. This back-end for front-end (BFF) architecture reduces chatter between the client and the Salesforce backend.

For teams who want to bring their own frontend framework — Next.js, Vue, Nuxt — the custom headless path is also supported. Salesforce provides the full SCAPI surface; you choose your own frontend framework and hosting provider. MuleSoft can also serve as an API gateway layer between the frontend and SCAPI for teams with existing integration middleware.

SCAPI hooks let you add custom endpoints to the Commerce API — returning your specific data with custom objects, formatted for your use case. This extensibility model means SCAPI is not a closed API surface; it grows with the needs of the implementation.

Section 5: Headless Identity — Authentication Without the Salesforce UI

Headless Identity separates the back-end authentication process from the front-end identity experience entirely. According to the Salesforce Headless Identity developer documentation: "Salesforce Headless Identity gives you the ability to separate back-end authentication processes from front-end identity experiences. By calling Headless Identity APIs, you can use the power of Customer Identity for authentication while maintaining complete control over the user experience in an off-platform or third-party app."

Three APIs are available. The Headless Login API authenticates users from off-platform apps. The Headless Registration API registers users without requiring them to interact with an Experience Cloud site UI. The Headless Forgot Password API handles password reset flows entirely within a custom experience. You can also link an SSO provider to create a native SSO experience in your custom application.

As the Experience Cloud setup documentation explains, these APIs are exposed through Experience Cloud — creating a lightweight EC site is a prerequisite for configuring Headless Identity, as the site controls enablement, access, and security settings for headless flows. However, your users never interact with the Experience Cloud site directly; it serves as the configuration layer while your custom app delivers the branded UX.

The Trailhead Headless Identity module describes the use cases clearly: branded mobile apps where "you want to fully design the user experience to suit your company's branding"; partner portals; single-page applications; and embedded commerce experiences. The key benefit is full control over UX — pixel-perfect branded experiences — while Salesforce handles authentication, token management, and customer account storage.

Section 6: When to Go Headless vs Stay On-Platform

Not every Salesforce implementation benefits from a headless approach. The decision hinges on the consumer experience requirements, team capabilities, and the cost-benefit trade-off between frontend flexibility and frontend maintenance overhead.

Rule of thumb: Go headless when the consumer experience demands it. Stay on-platform when internal users and standard workflows are the primary audience. As Trailhead's headless roles module notes, many components such as CDN caching, middleware, networking, and serviceability "don't come out of the box with a headless implementation" and must be added — a real operational cost that teams should plan for before committing to the architecture.

Section 7: Putting It All Together — A Headless Customer 360 Architecture

Consider a real-world scenario: an Australian government agency building a citizen-facing service portal. The agency needs a branded, mobile-first experience with sub-second response times, multi-channel support across browser and native app, and Salesforce handling all the back-end data, identity, and transactional logic. This is precisely the use case where headless Customer 360 earns its complexity cost.

The portal uses Headless Identity for citizen login and registration — a branded, mobile-friendly experience with no Salesforce UI visible to citizens. On authentication, the portal calls the Data Cloud Profile API and Data Graph API to retrieve the citizen's unified profile — service history, entitlements, and calculated insights drawn from multiple government department data sources, pre-joined into a single real-time JSON response. The CRM REST API handles case creation and service requests. For transactional citizen services such as permit applications and fee payments, SCAPI provides the Commerce backend. When the citizen's unified profile changes — say, a new benefit eligibility calculated insight crosses a threshold — a Data Cloud-Triggered Flow updates the CRM record and notifies the relevant case team. The entire frontend is a React application hosted on Heroku or Vercel, consuming Salesforce purely via APIs, with MuleSoft optionally serving as an API gateway layer for cross-cloud orchestration.

Conclusion: Salesforce as a Headless Backend Engine

The architectural shift to headless Customer 360 is not about abandoning Salesforce — it is about using more of Salesforce. Data Cloud's API-first semantic layer, SCAPI's composable commerce backbone, the three Headless Identity APIs, and the CRM REST and GraphQL APIs collectively expose a backend capable of powering any frontend experience on any channel. The platform's own evolution — from monolithic architecture to independent services, from first-party data centres to Hyperforce — makes headless a natural continuation of where Salesforce is heading.

The practical constraint is the same as it has always been: headless requires a developer team, frontend build time, and ongoing maintenance of the presentation layer. The trade-off is justified when the consumer experience demands it — pixel-perfect branding, sub-second performance, multi-channel reach to touchpoints Salesforce's own UIs cannot reach. When those conditions are present, the full headless API surface described in this post gives you everything you need to build it.