If you’ve spent years building storefronts, integrations, or backend logic in Salesforce Commerce Cloud (SFCC) using OCAPI, SCAPI, and Business Manager, switching to CommerceTools can feel like jumping into an entirely new paradigm. Where are the controllers? What happened to the familiar beforeGET and modifyAfterPOST hooks to intercept and modify API behavior? What’s the equivalent of custom objects? Where’s the Business Manager?
This article helps bridge that mental gap by mapping common SFCC concepts to their CommerceTools counterparts—starting with APIs, catalog, cart, and customer functionality.
Whether you’re an architect exploring headless options or a developer upskilling for a replatform, this guide is for you.
As a side note, one major strategic advantage of CommerceTools is that it offers a 60-day trial environment to businesses and developers. This hands-on access makes it easier for architects, developers, and even business stakeholders to explore the platform’s capabilities and assess fit early in their decision-making process.
By contrast, Salesforce Commerce Cloud does not provide public or time-bound trial access, which limits experimentation, learning, and certification opportunities. This restriction can act as a barrier for new developers and consultants who might otherwise advocate for the platform. In the long run, this could put SFCC at a disadvantage, as developer and architect familiarity plays a major role in influencing platform adoption and enterprise decisions.
🛠️ Business Manager vs Merchant Center
Before diving into APIs, it’s important to understand the role of each platform’s administrative console.
| Feature Area | SFCC Business Manager | CommerceTools Merchant Center |
|---|---|---|
| Catalog Management | Full control over products, categories, price books | Manage products, product types, categories, prices |
| User Roles & Permissions | Configure roles, permissions, organizations | Manage users and roles for project access |
| Content & Slots | Page Designer, content assets, slots, A/B testing | Very limited; content managed via external CMS |
| Custom Preferences | Site-specific preferences editable in BM | Not available – config lives in custom fields or external systems |
| Job Schedules | Built-in job scheduler and logs | No native jobs UI – use API/webhooks/integration |
| Order Management | View, edit, export orders | View and search orders, some limited edits |
| Customer Management | View/edit customer profiles and address books | View-only access; no rich customer admin tooling |
📌 Key Takeaway: The SFCC Business Manager is more mature and full-featured as an operational tool. In CommerceTools, the Merchant Center is API-first and minimal, meant to supplement—not replace—custom tooling. This means CommerceTools encourages businesses to build their own operational portals or use 3rd-party admin interfaces tailored to their workflow.
🌍 Multi-Region Support Using Stores and Product Selections
CommerceTools doesn’t use the concept of “Sites” like SFCC but enables similar multi-region or multi-brand configurations using:
Stores – Each store represents a region or brand (e.g., US Store, CA Store)
Product Selections – Assign products to specific stores as their catalog
Channels – Optional layer for inventory/pricing scoping
storeKey in API calls – Scopes customer, cart, and product responses to the intended store
📌 Example: To support both US and CA storefronts in the same project, you would:
Create two Stores (
us,ca)Assign product selections for each store
Use
GET /us/productsorPOST /ca/cartsto operate within a store’s context
📎 While customers exist at the project level, you can tag them to a store using Customer Groups or custom fields.
This gives you similar outcomes to SFCC’s site separation, but you manage the segmentation yourself through configuration and API conventions.
🔁 API Strategy and Architecture
| Area | SFCC | CommerceTools |
|---|---|---|
| API Style | OCAPI (REST), SCAPI (REST + OAuth2) | Pure API-first: REST and GraphQL |
| Auth | OCAPI: client ID & roles; SCAPI: SLAS (Shopper Login & API Access) | OAuth2: supports client_credentials, password, refresh_token flows |
| Headless Readiness | Added gradually (SCAPI, Page Designer APIs) | Built headless from the ground up |
| API Surface | Split across OCAPI and SCAPI (Shop, Data, Meta) | Uniform access via REST and GraphQL across all domains |
📌 Key Difference: CommerceTools treats APIs as the primary interface, not a layer on top of a monolith. There’s no “Business Manager” style fallback—everything goes through the API.
🛆 Product Catalog and Categories
For SFCC developers used to the layered catalog model—Master Catalog, Variation Groups, SKUs, and Navigation Catalogs—CommerceTools presents a flatter but more composable structure. Understanding how CommerceTools handles product modeling, variants, and attributes is key to transitioning smoothly.
| Concept | SFCC | CommerceTools |
|---|---|---|
| Catalog | Master Catalog + Site-specific Navigation Catalog(s) | No built-in separation; filtering by product selection or store context |
| Categories | Assigned per Navigation Catalog | Hierarchical; assignable to products within a store or globally |
| Product Structure | Master, Variation Group, Variant | Product with variants, defined via attributes and productType |
| Variation Attributes | Size, color, style etc. defined in variation model | Driven by productType + attribute definitions |
| Product Attributes | Custom and system attributes | Custom attributes via productType; typed and validated |
| SKU Level | Variant ID (SKU) managed in variation matrix | Each variant is its own object with SKU and attributes |
🔁 What Changes
No three-level hierarchy like Master → Variation Group → Variant. In CommerceTools, there are only products and variants based on the variant-defining attributes.
Product Types are mandatory. You define them with a schema of attributes before any product creation.
Each attribute is reusable and can be configured with
attributeConstraint = CombinationUniqueandlevel = variantto drive variant combinations.No site-specific price books — prices live directly on variants with
currencyCodeand optionalchannel.
⚠️ Gotchas & Tips
CommerceTools doesn’t enforce product uniqueness at the catalog level — you must manage slugs and keys carefully.
There is no visual matrix like SFCC’s VG editor — variant definitions are more flexible but require thoughtful schema.
All variant combinations must be explicitly created — CT does not auto-generate them.
The UI in Merchant Center uses “level: variant” to indicate variant-defining attributes. In the API, this is modeled using
attributeConstraint = CombinationUnique.
🧠 Clarification:
A ProductType in CommerceTools is not equivalent to a single variation attribute in SFCC—it’s broader. It defines the full schema for a product, including both product-level and variant-level attributes.
Attributes with
level: variantandattributeConstraint = CombinationUniquehelp resolve a product down to a specific variant (SKU). These are equivalent to SFCC Variation Attributes.Attributes with
level: productare more like standard attributes in SFCC—they apply to the entire product and do not influence variant resolution.
This separation allows CommerceTools to clearly distinguish between what identifies a variant and what describes a product.
🛒 Cart and Checkout Flow
| Capability | SFCC | CommerceTools |
|---|---|---|
| Cart Modification | Via pipelines/controllers or SCAPI | Atomic operations via API (addLineItem, removeLineItem) |
| Coupon Handling | Promotion engine with coupons | Discount codes + Cart Discounts via rules |
| Custom Logic | Custom hooks, pipelines, controllers | Can trigger AWS Lambda (or similar) via API extension hooks |
| Committing Cart | SubmitOrder or SCAPI call creates order | Explicit transition via API: cart → order |
| Inventory Check | Real-time check via inventory list / ATS | API-based channel inventory per SKU |
📌 Big Shift
In SFCC, cart and checkout behavior is controlled by embedded logic such as hooks and pipelines, which run inside the platform. In CommerceTools, this logic is externalized. You use API Extensions to trigger custom logic via HTTP calls before changes are committed—like validating a cart or syncing an order. This shift enables greater flexibility but also requires your team to manage cloud functions or middleware.
🔧 How to Add Custom Logic in Cart/Checkout (CommerceTools)
In SFCC, developers rely on hooks (beforePOST, modifyGET, etc.) to intercept or inject logic into the cart and checkout flows. CommerceTools takes a different approach.
To customize or extend cart/checkout behavior:
-
Use API Extensions to register event-driven triggers on specific resources (e.g., cart creation, order creation)
-
These triggers can call an external service like an AWS Lambda, GCP Cloud Function, or HTTP webhook endpoint
For example:
-
On
order.created, you could trigger a webhook that syncs to an ERP -
On
cart.changed, validate inventory or inject promotions
There is no direct inline logic execution within CommerceTools like SFCC hooks. Instead, CT encourages decoupled, serverless logic that lives in your infrastructure.
✅ Pro Tip:
Use CommerceTools’ API Extension mechanism to replicate SFCC-style logic points. These extensions:
-
Can intercept changes before they’re committed to the DB (e.g., validate a cart before save)
-
Allow asynchronous workflows (e.g., trigger webhook on order create)
-
Provide language-agnostic flexibility via HTTP
Unlike SFCC’s inline controller logic or hook files, CommerceTools encourages decoupling core logic into cloud-native or external services.
👤 Customer Management & Sessions
| Feature | SFCC | CommerceTools |
|---|---|---|
| Customer Types | Registered or Guest | Registered or Anonymous |
| Login | Handled via OCAPI/SCAPI or storefront login | OAuth2 password grant or token-based login APIs |
| Session Tokens | SCAPI uses bearer tokens (SLAS); OCAPI uses cookie/session | OAuth2 bearer tokens with expiration and refresh flows |
| Customer Scope | Scoped per site (login required on each) | Global to project; can filter/group using custom fields |
| Password & Reset | Storefront flows or OCAPI | Handled via Customer API or Compose Frontend login flows |
| Custom Attributes | Defined in Business Manager | Typed custom fields defined on customer schema |
📌 Clarification for SFCC Developers:
Both platforms use OAuth-based bearer tokens to authenticate and authorize customer requests. You pass the token with every API call, and both support guest (anonymous) and registered customer flows.
In SFCC, SLAS (Shopper Login and API Access Service) is available only with SCAPI—not OCAPI. It provides a managed identity layer that handles token issuance, refresh, expiration, and device activation flows. For OCAPI, authentication is handled through client credentials configured with specific roles.
In CommerceTools, the authentication flow is standards-based (OAuth2), but you manage token storage, refresh, and lifecycle within your frontend or middleware (e.g., Composable Frontend, the official frontend framework offered by CommerceTools, formerly known as Frontastic).
🔸 So, for most implementations, the developer experience is functionally similar, especially with the right framework. The key difference is that CommerceTools doesn’t provide a proprietary session management layer like SLAS—you either roll your own or adopt a tool that does.
📌 Developer Note: There’s no Business Manager-style UI to manage customer data in CommerceTools—you’ll likely build your own admin interface or connect a 3rd-party system via API.
Wrapping Up: From SFCC to Composable Thinking
CommerceTools removes the concept of site-specific logic and server-side pipelines. Instead, it gives you clean APIs, well-defined resources, and full flexibility to assemble your stack using modern frontend, backend, and middleware technologies.
As an SFCC veteran, you’ll likely miss some out-of-the-box conveniences (e.g., Business Manager tools or controller-based flows), but you’ll gain far more in terms of architecture flexibility, speed, and future-proofing.
🧠 Mindset Shift: CommerceTools expects you to think API-first, not console-first. Most platform capabilities—including product, cart, checkout, and even promotions—are driven by APIs, not by built-in tools or wizards. While the Merchant Center provides some UI for business users, serious customization happens outside the box.
In fact, CommerceTools is designed to act as a modular commerce engine—just one part of your broader digital commerce stack. You may combine it with a custom frontend (like Composable Frontend), third-party CMS, payment processor, or tax engine, all loosely coupled via API.
This modular, API-first mindset is key to unlocking the power of composable commerce.