Headless Salesforce Commerce Cloud: Was das für euer Frontend wirklich bedeutet

„Headless SFCC" wird in Ausschreibungen und Architektur-Docs oft wie ein einzelner Schalter behandelt: an oder aus. In Wirklichkeit beschreibt der Begriff, welche API-Schicht euer Frontend anspricht und wie viel Rendering-Logik dabei noch bei Salesforce liegt. Das ist keine Ja-/Nein-Frage, sondern eine Reihe von Architektur-Entscheidungen. Dieser Beitrag klärt, was headless auf SFCC technisch bedeutet, bevor ihr überhaupt in die Frage einsteigt, mit welchem Frontend ihr das umsetzt.

Der Ausgangspunkt: Was SFCC „von Haus aus" liefert

Salesforce Commerce Cloud kommt mit der Storefront Reference Architecture (SFRA) aus: einem serverseitig gerenderten Storefront-Template auf Basis von Node.js und ISML-Templates, das direkt in der Commerce-Cloud-Instanz läuft. SFRA ist kein Add-on, sondern der Standard-Auslieferungsweg, für den die meisten SFCC-Implementierungen ursprünglich gebaut wurden. Rendering, Business-Logik und Backend sitzen hier in derselben Plattform.

Headless bedeutet an dieser Stelle: Das Rendering wird aus SFCC herausgelöst. Statt dass die Plattform HTML ausliefert, liefert sie Daten über eine API, und ein separates Frontend rendert die Seite. Damit verschiebt sich die Entscheidung nicht auf „SFRA oder headless", sondern auf welche API-Schicht das entkoppelte Frontend nutzt und wie viel von der bisherigen SFRA-Logik mitgenommen werden muss.

Die zwei API-Schichten, die den Unterschied machen

OCAPI (Open Commerce API) ist die ältere REST-API von SFCC. Sie deckt Shopping- und Data-Endpoints ab und war lange der einzige Weg, SFCC ohne SFRA-Rendering anzusprechen. OCAPI ist funktional, aber nicht für moderne Headless-Frontends konzipiert: Versionierung, Rate-Limits und die Endpoint-Struktur folgen der SFRA-Denke.

SCAPI (Salesforce Commerce API) ist die aktuelle API-Generation und der Weg, den Salesforce für neue Headless-Projekte vorsieht. SCAPI ist granularer aufgebaut, unterstützt Custom-APIs für eigene Business-Logik und ist die Grundlage, auf der auch Salesforces eigenes PWA Kit aufsetzt. Wer heute ein Headless-Setup auf SFCC plant, baut in aller Regel auf SCAPI, nicht auf OCAPI, weil OCAPI schrittweise auslaufen wird und für neue Custom-Endpoints ohnehin nicht vorgesehen ist.

Diese Unterscheidung ist der erste Punkt, an dem „headless SFCC" konkret wird: Es ist kein einheitlicher Zustand, sondern eine API-Wahl mit direkten Konsequenzen für Wartbarkeit und Zukunftssicherheit.

Drei Wege, headless auf SFCC umzusetzen

1. SFRA bleibt, wird aber nicht mehr als reines Server-Rendering genutzt. Manche Teams behalten SFRA für Teile der Logik (Checkout-Flows, Promotions) und lösen nur einzelne Frontend-Bereiche heraus. Das ist selten eine saubere Zielarchitektur, aber in Migrationsphasen häufig der reale Zwischenzustand.

2. PWA Kit. Salesforces eigenes React-basiertes Storefront-Toolkit, das direkt auf SCAPI aufsetzt und über die Managed Runtime gehostet wird. PWA Kit nimmt euch viel Integrationsarbeit ab, bindet euch aber an Salesforces Rendering- und Hosting-Modell. Für Teams, die schnell von SFRA weg wollen, ohne ein Frontend komplett neu zu bauen, ist das der naheliegende erste Schritt.

3. Vollständig entkoppeltes Frontend. Ein eigenständiges Frontend, das ausschließlich über SCAPI (und ggf. ergänzenden Custom-APIs) mit SFCC spricht, unabhängig von PWA Kit oder SFRA gehostet und gerendert. Das ist der Weg mit der größten Kontrolle über Rendering-Strategie, Performance und Composable-Integrationen, aber auch der mit dem größten Eigenanteil an Integrationsarbeit.

Die Bewertung, welcher dieser drei Wege für euren Anwendungsfall am sinnvollsten ist, ist bewusst nicht Thema dieses Beitrags. Sie hängt stark von bestehendem Custom-Code, Team-Kapazität und Zeitrahmen ab. Eine ausführliche Gegenüberstellung findet ihr in unserem Vergleich SFCC-Frontend-Optionen: SFRA, PWA Kit, Storefront Next oder FMP-Decouple, speziell zu PWA-Kit-Alternativen in unserem Buyer Guide zu PWA-Kit-Alternativen.

Was bei jedem headless SFCC-Setup im Backend bleibt

Unabhängig davon, welchen Weg ihr wählt, bleiben bestimmte Verantwortungen bei SFCC:

• Produktkatalog und Preislogik. Katalog-Struktur, Preisbücher und Promotions-Regeln werden weiterhin in der Business Manager konfiguriert und über SCAPI ausgeliefert, nicht im Frontend nachgebaut.
• Order-Management und Checkout-Kernlogik. Bestellabwicklung, Zahlungs-Integrationen und Order-Status laufen über SFCC-Backend-Prozesse, selbst wenn das Checkout-UI im entkoppelten Frontend liegt.
• Suche und Empfehlungen (Einstein). Sofern Einstein Search/Recommendations genutzt wird, bleibt die Such- und Empfehlungslogik serverseitig; das Frontend konsumiert die Ergebnisse über API.
• Content-Blöcke aus Page Designer, sofern weiterhin genutzt, werden über API ausgeliefert und müssen im entkoppelten Frontend nachgebaut, nicht per iFrame eingebunden werden.

Das bedeutet: Headless auf SFCC ist nie „Backend komplett ersetzen". Es ist eine Entscheidung darüber, wo die Rendering-Grenze verläuft, nicht darüber, ob SFCC als Commerce-Engine bestehen bleibt.

Die Entscheidungen, die tatsächlich anfallen

Wenn ihr headless SFCC plant, sind das die konkreten Weichenstellungen, nicht „welches Frontend-Framework":

1. API-Fundament: SCAPI als Zielzustand, OCAPI nur für bestehende Legacy-Integrationen, die (noch) nicht migriert sind.
2. Rendering-Ownership: PWA Kit und Salesforces Managed Runtime nutzen, oder Rendering und Hosting vollständig selbst kontrollieren.
3. Content-Modell: Page Designer weiter als Content-Quelle nutzen und über API ausliefern, oder Content-Komposition in ein eigenständiges Frontend-Layer verlagern.
4. Migrationspfad: Big-Bang-Wechsel weg von SFRA, oder schrittweise Herauslösung einzelner Seitenbereiche bei laufendem Betrieb.

Diese vier Punkte bestimmen, wie viel architektonische Freiheit ihr am Ende habt, und wie viel Integrationsaufwand auf euer Team zukommt. Wer sich zusätzlich fragt, wie sich das operative Modell dahinter einordnet, findet eine Einordnung in unserem Beitrag Frontend as a Service für Salesforce Commerce Cloud erklärt.

Wo Laioutr in diesem Bild ansetzt

Als Composable-Headless-Frontend-Layer setzt Laioutr direkt auf SCAPI auf und übernimmt die Rendering-Ownership vollständig, ohne dass ihr die Content- und Commerce-Logik in SFCC neu aufbauen müsst. Das entspricht der dritten Variante oben: entkoppeltes Frontend, aber ohne dass ihr die gesamte Integrationsarbeit selbst tragt. Für SFCC-Teams heißt das konkret: Business Manager, Preislogik und Order-Management bleiben unverändert in Salesforce, während Layout, Kampagnen-Komposition und Editing direkt im visuellen Editor liegen, nicht im Dev-Backlog.

Häufige Fragen

Ist OCAPI für neue SFCC-Projekte noch eine Option? Für laufende Integrationen ja, für neue Custom-Endpoints nicht mehr sinnvoll. Salesforce entwickelt neue Funktionalität ausschließlich auf SCAPI, entsprechend liegt bei Neuprojekten der klare Fokus dort.

Muss ich PWA Kit nutzen, um headless zu werden? Nein. PWA Kit ist eine von mehreren Optionen, keine Voraussetzung für Headless-Betrieb. Ein vollständig entkoppeltes Frontend kann direkt gegen SCAPI arbeiten, unabhängig von PWA Kit und der Managed Runtime.

Wird SFCC dadurch überflüssig? Nein. Katalog, Preislogik, Promotions und Order-Management bleiben SFCC-Verantwortung. Headless verändert, wo gerendert wird, nicht, wer die Commerce-Logik betreibt.

Nächste Schritte

Wenn ihr gerade entscheidet, wie euer headless SFCC-Setup aussehen soll, buche eine 30-Minuten-Demo und wir zeigen, wie ein SCAPI-natives Frontend ohne PWA-Kit-Bindung konkret aussieht.

Weitere Themen aus der Laioutr-Plattform

• Headless Frontend für Salesforce Commerce Cloud
• Composable Headless Frontend bei Laioutr
• Agentic Frontend Management Platform

Über den Autor: Marcel Thiesies ist Co-Founder von Laioutr und beschäftigt sich täglich mit der Frage, wie Commerce-Teams ihre Backend-Investition schützen, während sie das Frontend modernisieren.