Mapping SFCC to CommerceTools: Part 1 – Architecture, APIs, and Core Commerce Features

Tech Programmer — Sun, 06 Jul 2025 22:27:52 +0000

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/products or POST /ca/carts to 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 = CombinationUnique and level = variant to drive variant combinations.
No site-specific price books — prices live directly on variants with currencyCode and optional channel.

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: variant and attributeConstraint = CombinationUnique help resolve a product down to a specific variant (SKU). These are equivalent to SFCC Variation Attributes.
Attributes with level: product are 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.

E-Commerce Platforms – Tech-Freaks.com