SAP S/4HANA Public Cloud Integration Options: What Is Possible and How to Choose

SAP S/4HANA Cloud Public Edition integrates with other systems only through released interfaces: OData and SOAP APIs, business events and CDS-based data extraction, each switched on by a communication arrangement. Direct table access and modifications are not part of the model. Within that frame you choose per interface between a synchronous API call, an event, a replication or an extraction, usually with SAP Integration Suite in between.

TL;DR: Use only APIs that SAP has published on the SAP Business Accelerator Hub; SAP’s API Policy makes this a rule, not only advice. Open each interface with a communication arrangement and prefer certificate-based authentication. Synchronous APIs for questions that need an answer now, events for “something changed”, extraction for analytics. For Sales and Service Cloud V2, start with SAP’s standard packages. For everything else, write down per interface which pattern, which API and who owns the errors.

I have worked with SAP landscapes from on-premise systems to RISE with SAP and the public edition. The public edition asks the same integration questions, but the set of answers is smaller and better defined. That is an advantage if you know the set.

The ground rule: released APIs only

SAP lists every public interface of the public edition on the SAP Business Accelerator Hub. On 31 October 2026 the package listed 869 APIs in our count: 371 OData V4, 205 OData V2 and 293 SOAP services. Business events are a separate package with 148 events, and CDS views for extraction are grouped per business area.

The overview of APIs in the public edition adds the rule that shapes every design: each API on the Business Accelerator Hub is associated with at least one communication scenario. No scenario, no access.

This is also contractual. The SAP API Policy, in its version of April 2026, states that customer and third-party applications must not access or invoke APIs that are not published APIs. The same policy explicitly allows published APIs for integrating SAP applications with customer or third-party solutions, and it reserves throttling and restricts large-scale data extraction outside SAP-endorsed paths.

Communication arrangements: the switch for every interface

Communication management has four building blocks:

• Communication scenario: a design-time description of how two partners communicate, with inbound and outbound services and supported authentication methods. SAP delivers scenarios named SAP_COM_xxxx; you can define your own.
• Communication user: the technical user the partner logs on with for inbound calls.
• Communication system: the partner system, with its host and the users for both directions.
• Communication arrangement: binds scenario and system and activates inbound and outbound services.

Authentication options are basic, X.509 client certificates, OAuth 2.0 and SAML. SAP’s setup page for business partner replication puts it plainly: authentication with mTLS is recommended, basic authentication is only for compatibility. We use certificates wherever both sides support them and track their expiry dates like any other operating task.

The integration patterns

1. Synchronous APIs: ask and get an answer

OData and SOAP APIs cover create, read, update and simulate for most business objects. Typical uses: a CRM simulating a sales order for price and availability, a web shop creating an order, a portal reading open invoices. This is the right pattern when the caller needs the answer in the same moment. It is the wrong pattern for “tell me when something changes”: polling an API every few minutes wastes calls and still arrives late.

2. Business events: react to changes

S/4HANA publishes business events in the CloudEvents format through Enterprise Event Enablement, for example when a business partner or a sales order changes. The event says what changed; the subscriber calls the API for details if it needs them.

To deliver events you connect a broker. SAP notes in its developer tutorials that the standalone SAP Event Mesh service is no longer available for new customers without existing access. The options are the Event Mesh capability in SAP Integration Suite, SAP Integration Suite, advanced event mesh with communication scenario SAP_COM_0492, and SAP Cloud Application Event Hub, where a formation generates the system and arrangement for you. Which broker fits depends on your licences and on whether non-SAP systems need to subscribe.

3. Data extraction: for analytics, not for processes

For SAP Datasphere, the scenario SAP_COM_0532 feeds ABAP CDS pipelines, including delta through change data capture. It needs an authorization group that lists the CDS views you allow. Extraction is for reporting and data products. It is not a way to drive processes in another system, and the API Policy limits bulk extraction outside such endorsed paths.

4. Master data replication

For master data such as business partners and products, SAP offers replication scenarios, for example SOAP-based business partner replication with SAP_COM_0008, and distribution through SAP Master Data Integration. Replication keeps a copy in the target system and sends changes as they happen. Use it when the other system needs the data locally, as a CRM does for accounts and products.

5. Your own APIs, still on released ground

When no SAP API fits, you build one without leaving the rules:

• The Custom Communication Scenarios app exposes your own services.
• A custom CDS view can be published as an external OData API. SAP notes that this is not meant for one-off mass extraction and supports basic authentication only.
• Custom business objects can generate an OData service.
• With developer extensibility in ABAP Cloud, you build RAP services on released objects and expose them through your own communication scenario. Sofiene Karaja explains the ABAP side in Embedded Steampunk and ABAP Cloud.

6. BAPIs, IDocs and on-premise systems

The public edition is not entirely without the classic techniques, but they are narrow. SAP’s page on BAPIs and IDocs lists a fixed set of them in predefined communication scenarios, inbound only. BAPIs are called through WebSocket RFC from cloud systems or through SAP Cloud Connector from on-premise systems. IDocs are supported only via SOAP, not via RFC. For calls from S/4HANA into your own network, the scenario SAP_COM_0574 uses the SAP BTP connectivity service and Cloud Connector for HTTP and RFC. If an old interface depends on a custom RFC module, plan to rebuild it on an API.

Middleware: Integration Suite, or something else

SAP’s integration overview names SAP solutions, partner solutions, third-party cloud and on-premise systems and custom applications as integration partners. Nothing in SAP’s documentation forbids third-party middleware or a direct call to a released API.

In practice SAP Integration Suite on SAP BAIP is the default for one reason: SAP’s prepackaged integration content runs there. Mapping, retries, monitoring and alerting come with it. A direct call is fine for one simple, synchronous use case with a single owner. As soon as several systems, mappings or error handling are involved, you rebuild middleware in your own code.

For the decision itself, SAP’s Integration Solution Advisory Methodology (ISA-M) is a useful frame. It is technology-agnostic and classifies interfaces by integration style, so the choice of technology follows the pattern, not the other way round.

Connecting Sales Cloud V2 and Service Cloud V2

For SAP’s own CX applications, start with the standard packages on the Business Accelerator Hub:

Package	Covers
Sales Processes with SAP S/4HANA Cloud Public Edition	Follow-up quotes and orders, simulation, sales order replication
Master Data with SAP S/4HANA Cloud Public Edition	Business partners, products, org data, pricing, code lists
Customer Insights Integration with SAP S/4HANA	S/4HANA documents such as invoices in the account view

These run as iFlows in SAP Cloud Integration. If your contract includes SAP’s integration setup service, SAP sets up and manages the flows within a defined scope; otherwise you deploy them in your own tenant. How a sales order travels through these flows is described in my post on sales orders from Sales Cloud V2 to S/4HANA Public Cloud, and the overall picture in Sofiene Karaja’s integration architecture.

Connecting third-party systems

For a web shop, a warehouse system, a bank or a supplier platform, the same rules apply. Find the released API or event on the Business Accelerator Hub, check which communication scenario it belongs to, and decide where the mapping lives. Three questions settle most cases:

1. Does the other side need an answer now? Then a synchronous API.
2. Does it need to know that something changed? Then an event, with an API call for details.
3. Does it need a full copy for analysis? Then extraction, not a process interface.

Decision guide

Requirement	Pattern	S/4HANA side
CRM needs price and availability during a quote	Synchronous API (simulation)	SAP scenario, e.g. SAP_COM_0109
CRM or shop needs current customers and products	Replication	Standard replication scenario
Several systems react to a changed order	Business events	Event channel with a broker
Reporting and data products	CDS extraction	SAP_COM_0532
No SAP API fits	Own API on released objects	Custom communication scenario
Legacy system on premise	API through Cloud Connector	SAP_COM_0574 for outbound

Clean core is the frame, not a project

SAP describes clean core levels from A to D. Level A means extensions that use only publicly released and stable SAP interfaces with formal stability contracts. In our reading, that is the space the public edition gives you for integration: the released APIs, events and scenarios described above. Staying there is what keeps the quarterly upgrades uneventful.

What Spadoom does

We design and build the interfaces of SAP S/4HANA Public Cloud with the same team that implements the ERP and the CX side. That covers the interface inventory with pattern and owner per line, communication arrangements and certificates, the standard packages for Sales and Service Cloud V2, own iFlows where the standard ends, and monitoring before go-live. How this fits into ERP and CX projects is on our page on the SAP partner in Switzerland.

Want to go through your interface list? Talk to us.

Frequently asked questions

How can I integrate SAP S/4HANA Cloud Public Edition with other systems?

Only through released interfaces: OData and SOAP APIs listed on the SAP Business Accelerator Hub, business events, and CDS-based extraction, each enabled by a communication arrangement. In between you usually run SAP Integration Suite, but SAP’s documentation does not rule out other middleware or a direct call to a released API.

Can I use BAPIs, RFC or IDocs with S/4HANA Public Cloud?

Only to a limited extent. SAP releases a fixed list of BAPIs and IDocs in predefined communication scenarios, inbound only. BAPIs are called through WebSocket RFC from cloud systems or through SAP Cloud Connector from on-premise systems, and IDocs are supported only via SOAP. Anything outside that list is not available as an interface.

What is a communication arrangement?

The switch that opens an interface in S/4HANA Cloud Public Edition. It combines a communication scenario, which defines the inbound and outbound services and authentication methods, with a communication system for the partner and a communication user. Every API on the SAP Business Accelerator Hub belongs to at least one communication scenario.

Do I need SAP Integration Suite to connect Sales Cloud V2 and S/4HANA Public Cloud?

For SAP’s standard integration content, yes: the packages for master data and sales processes run as iFlows in SAP Cloud Integration. If your contract includes SAP’s integration setup service, SAP runs them for you; otherwise they run in your own Integration Suite tenant.