Integration Options for SAP Commerce Cloud: Choosing the Right Channel in 2026

Every integration decision on an SAP Commerce project is really three decisions: where the logic runs (inside the platform or beside it), how the data moves (synchronously or asynchronously), and when the configuration binds (build time or runtime). Teams that answer those three consciously end up with upgradeable systems; teams that default to "write another extension" end up with a platform whose upgrade estimate has a comma in it.

This guide maps the current (2211-era) integration menu, with the strengths, limits, and honest failure modes of each option, and the decision framework for choosing.

Three Principles Before Any Option#

1. Side-by-side beats in-app. Logic outside the platform deploys independently, scales independently, rolls back without touching production commerce, and is written in whatever stack your team is fastest in. Logic inside the platform rides the commerce release train forever.
2. Asynchronous beats synchronous. Every synchronous call in a storefront flow donates its latency and its failure probability to your conversion funnel.
3. Runtime configuration beats build-time code. Integration Objects, webhooks, and destinations configured in Backoffice change without a 40-minute CCv2 build. Extensions do not.

Following these shrinks your custom extension count, which is the single best predictor of how painful your next platform upgrade will be.

The Options#

Integration APIs (OData): The Default Answer for Data#

The platform's Integration Objects (IOs) describe business entities declaratively; each IO becomes an OData service with full CRUD, an EDMX schema, and monitoring. When something needs to push data in or pull data out, this is the first option to evaluate, and the workflow is almost entirely runtime:

1. Model the IO (Backoffice Integration UI, ImpEx, or the MetaAPI). Missing attributes can be added as runtime attributes; formatting, enrichment, and flattening are handled by virtual attributes. Both are runtime-configured, which also means they do not survive initialization and must be promoted between environments deliberately (the MetaAPI is the clean way to keep IOs consistent across local, stage, and production).
2. Create an Inbound Channel Configuration for authentication (Basic or OAuth2). IOs are not exposed until you do; there is no accidental public endpoint.
3. Assign access rights per IO.
4. Test against the generated endpoint.

ImpEx to define an IO, so it lives in your repository rather than someone's Backoffice session:

INSERT_UPDATE IntegrationObject; code[unique=true]; integrationType(code)
; InboundStockLevel ; INBOUND

INSERT_UPDATE IntegrationObjectItem; integrationObject(code)[unique=true]; code[unique=true]; type(code); root[default=false]
; InboundStockLevel ; StockLevel ; StockLevel ; true
; InboundStockLevel ; Warehouse  ; Warehouse  ;

INSERT_UPDATE IntegrationObjectItemAttribute; integrationObjectItem(integrationObject(code), code)[unique=true]; attributeName[unique=true]; attributeDescriptor(enclosingType(code), qualifier); unique[default=false]
; InboundStockLevel:StockLevel ; productCode ; StockLevel:productCode ; true
; InboundStockLevel:StockLevel ; available   ; StockLevel:available   ;
; InboundStockLevel:StockLevel ; warehouse   ; StockLevel:warehouse   ;
; InboundStockLevel:Warehouse  ; code        ; Warehouse:code         ; true

Practical guidance from production use: reuse IOs where a consumer can tolerate extra fields (fewer objects to govern beats perfectly tailored payloads), lock the Backoffice Integration UI perspective down to integration owners, and if OData traffic ever pressures the API aspect, that is a scaling conversation with SAP support, not a reason to move the integration in-app.

SAP Integration Suite: The Strategic Middleware#

For SAP-to-SAP integration (S/4HANA, ERP, Customer Data Cloud, Emarsys and the rest of the CX portfolio), pre-built integration packages on SAP Integration Suite consume the same Integration APIs underneath. The iFlows handle mapping, orchestration, and error handling; the Integration Extension Pack (its own release artifact since 2005, on its own cadence) delivers the commerce-side inbound and outbound services.

Two version facts that bite: the extension pack version must be compatible with your commerce update release, and an iFlow existing in the API Business Hub does not guarantee the matching commerce-side service exists yet; both ends must ship before the integration works. Check both compatibility matrices during release planning, not during integration testing.

When the pre-built packages do not fit, custom IOs plus custom iFlows use exactly the same machinery, which keeps even bespoke integrations on the supported path.

Events: Webhooks and OutboundSync#

Events are the platform's asynchronous outbound story, and the two consumers have opposite performance envelopes. Learn the table; it prevents the most common event-architecture mistake:

Webhooks subscribe to model events at runtime: a Backoffice configuration names the event, an optional script filters payloads, and a destination receives the POST. Right-sized examples: back-in-stock notifications, loyalty-points triggers on order completion, alerting an account manager when a B2B order is rejected. Failed deliveries land in the Event Dead Letter Queue (Backoffice, System, API), which someone must actually monitor, because "not guaranteed delivery" is a design property, not a bug you can file. Note the scaling detail: events export from the aspect where they are registered, typically backoffice, so a chatty webhook can degrade Backoffice nodes.

OutboundSync is the bulk channel: an IO defines the payload, a change stream defines what counts as changed (with delta detection), and a cronjob ships accumulated changes to the destination. Inventory to an external OMS, prices to a cache, orders to analytics. It trades latency for reliability and volume, which is the right trade for data replication and the wrong one for "notify me now".

Defining a new event type still requires a Java event class, hence a build and deploy; everything downstream of the event is runtime.

Side-by-Side Logic: Kyma and Friends#

For business logic that does not belong inside commerce (the "save for later" service, fractional-unit pricing, geo-restrictions, ad-hoc translation), SAP's managed runtime is SAP BTP, Kyma runtime: managed Kubernetes plus serverless functions, connected to commerce through the event and API machinery above. Kubernetes-grade scaling, monitoring, and namespace isolation come with it.

The architectural point survives even if you never buy Kyma: commerce exposes events and APIs; the extension consumes them from wherever you run containers (any hyperscaler, any stack). The companion guide on event-driven integrations builds a full example.

Cloud Hot Folders: Files, Done Properly#

File-based integration on CCv2 runs on Cloud Hot Folders over Azure Blob Storage: drop a CSV in a container, a channel picks it up, mappings convert it to ImpEx, and processed files land in archive or error folders. Provisioned with every CCv2 environment; new channels and mappings are code, so they ride the build cycle. Processing belongs on the background processing aspect (two nodes minimum in production gives resiliency). Files count against your storage quota. The full treatment, including local testing against Azurite and tuning, is in the Cloud Hot Folders guide in this series.

ImpEx: The Workhorse With Sharp Edges#

ImpEx remains the bulk data tool for setup, migration, and administration, executable via HAC, the ImpEx API, cronjobs, and Backoffice wizards, with distributed mode for cluster-scale imports. Its integration role is mostly as the payload format that hot folders and migrations generate. Operational cautions that deserve repeating: HAC validation is syntactic only (real validation happens at execution); ImpEx typically runs as admin so its changes bypass audit; and manual ImpEx cronjobs cannot be aborted mid-run, so a runaway import on production is a genuinely bad afternoon. Lock down who can execute ImpEx accordingly.

Data Hub: Do Not Start, Do Finish Migrating#

Data Hub stopped being strategic years ago, receives no new features, and the Integration APIs plus Integration Suite are its designated replacement. If a legacy solution still runs it, the guidance is unambiguous: freeze customization, and put the migration to Integration APIs on the roadmap with a date, because every quarter of new Data Hub coupling is added migration cost. No new project has a reason to touch it.

Classic In-App Extensions: The Last Resort, Priced Honestly#

Sometimes the answer really is a custom extension: deep platform behaviour changes, custom pricing logic in the calculation path, things the extension points exist for. The platform supports this well. The discipline is accounting for the whole invoice, not just the development sprint:

• Bug fixing and support, forever
• Regression and performance testing on every update release (and there is roughly one per month on 2211)
• Upgrade impact, multiplied if the extension strayed from documented extension points
• The build-and-deploy tax on every change that a runtime option would have avoided

When an in-app customization is the only fit, it is frequently cheaper to renegotiate the business requirement than to build it. Ask that question out loud in refinement; it is astonishing how often "must be synchronous and in-platform" softens when the maintenance cost is on the table.

Choosing: The Short Interrogation#

Work down; stop at the first yes.

1. Does a pre-built integration or SAP Store app cover it? Buy, do not build. Check the roadmap too; a package shipping next quarter may beat your build finishing next quarter.
2. Is it master data or transactional data moving between systems? Integration APIs, directly or through Integration Suite. Files only when the counterpart genuinely cannot speak HTTP, then Cloud Hot Folders.
3. Is it "react when something happens"? Webhook for notifications, OutboundSync for replication. Check the throughput/reliability table before choosing.
4. Is it new business logic? Side-by-side service consuming events and OCC/Integration APIs. Kyma if you want it managed by SAP.
5. None of the above fit? Classic extension, at documented extension points, with the full cost acknowledged in the estimate.

The pattern behind the whole menu: the platform has spent years growing runtime-configurable, API-first integration surfaces precisely so that your code does not have to live inside it. Every integration you keep out of the core is an upgrade you just made cheaper.