SAP S/4HANA API Integration
SAP S/4HANA runs three ways: Public Cloud, Private Edition under RISE and on-premise, each reached a different way and secured a different way. Maesn covers all three through one REST API, over OData and SOAP, so the SAP S/4HANA interface your product talks to stays the one it already has.
All S/4HANA complexity covered within Maesn
An SAP integration rarely fails on the object you want. It fails on the deployment that decides the path, the authentication that differs with it and the release levels that move underneath you. Maesn absorbs all three.
One method across all three
Public Cloud is reached directly; Private Edition and on-premise through the customer's SAP BTP. Maesn routes over OData or SOAP, so none of it branches in your code.
Unified to one account key
Communication users, X.509 certificates, OAuth 2.0, principal propagation. Maesn settles the method per connected customer and hands you one account key.
Version differences handled
Public Cloud updates automatically to the latest release; older on-premise levels miss some released APIs. Maesn resolves availability per release and falls back where needed.
What is left on your side is one REST call against a data model you implement once. Which S/4HANA a customer runs stops being a project and becomes a setting.
A short call is usually enough to tell whether Maesn fits your use case.
One API above every deployment
Which S/4HANA a customer runs is the first and most important distinction: it decides what is technically reachable and how it is reached. Maesn handles the three as distinct target systems and exposes one interface above them.
| Deployment | Operation and releases |
|---|---|
| Cloud, Public Edition | SAP-hosted, multi-tenant, automatic updates, always on the latest release (2408, 2502, 2508 and onward) |
| Cloud, Private Edition (RISE) | SAP-managed, run on a hyperscaler (AWS, Azure, Google Cloud) or delivered by a hosting partner. Same code base and release levels as on-premise |
| On-premise | Customer- or partner-hosted, two-year release cadence (2023, 2025, 2027), and the customer controls the upgrade |
Maesn follows SAP Clean Core Integration Principles
Traditional and proprietary interfaces like direct RFCs, classic BAPIs or IDocs are left aside. Maesn builds only on SAP's clean, versioned standard APIs, OData and SOAP web services, the way SAP recommends. That clean connection runs through the SAP Business Technology Platform, so the ERP core stays untouched.
The reason is portability as much as hygiene. A BAPI or an IDoc ties an integration to one deployment and reaches into the customer’s core, so the same customer moving from on-premise to RISE would mean rebuilding it. Released APIs behave the same across all three. Where an older release level is missing a released API for an object, Maesn falls back to a CDS view or a small custom OData service and keeps the outside interface identical, which is the same approach customisation handling takes everywhere else in the catalogue: the system-specific part is absorbed rather than passed on to your schema.
Two standard protocols, OData and SOAP
Maesn works with the APIs from the official SAP Business Accelerator Hub. OData carries the bulk of read and write, SOAP covers the finance postings OData does not. Both carry across Public, Private and on-premise, so the interface you build against stays the same on every deployment.
Standard read and write
REST access to released APIs from the SAP Business Accelerator Hub, the default wherever it exists, across Public, Private and on-premise.
Postings OData does not cover
Certain finance postings and older scenarios are available only as web services. Maesn speaks both inward and returns one REST and JSON interface outward.
| Protocol | What it carries | Available in |
|---|---|---|
| OData (V2/V4) | Standard REST access to released APIs, read and write | All three deployments |
| SOAP / Web Services | Finance postings and older scenarios OData does not cover, sometimes the only option per object | All three deployments |
Maesn uses OData and SOAP only. Proprietary interfaces like BAPI/RFC or IDoc stay off the integration on purpose: using them would tie the integration to one deployment and reach into the customer’s core. Where a released OData API is missing for an object on an older release, Maesn resolves this internally and keeps the same interface on the outside, so the integration stays clean-core and portable.
None of that reaches your client. OData is a REST-based protocol with conventions of its own, from the way queries are written to the shape of the response envelope, and SOAP is a different world again. Maesn speaks both inward and returns plain REST and JSON outward, so whether a given object happens to arrive over OData or over SOAP is settled on our side. Your team writes the same request style here as for every other system it reaches.
Direct for Public Cloud, through BTP for the rest
Public Cloud is reached directly over OData. Private Edition and on-premise are reached through the customer's SAP BTP, with the SAP Cloud Connector for the tunnel and API Management as the gateway. A directly exposed mTLS endpoint stays available as the exception.
| Variant | Protocol | Connectivity | Authentication |
|---|---|---|---|
| Public Cloud | Released OData | Direct HTTPS call, no BTP | Communication Arrangement plus OAuth or certificate |
| Private Edition (RISE) | OData, plus CDS or custom where needed | Customer's SAP BTP: Cloud Connector and API Management | Certificate or OAuth |
| On-premise | OData, plus CDS or custom where needed | Customer's SAP BTP, or reverse proxy with mTLS as the exception | Certificate or OAuth |
API Management sits as a thin pass-through for the released OData and SOAP APIs, with no transformation and no orchestration on BTP. That boundary is deliberate: the gateway is a door, not a place where logic lives, so nothing of yours depends on how a given customer has configured their platform.
What BTP does, and what stays optional
For Private Edition and on-premise the connection runs through the customer's SAP BTP, with the Cloud Connector for the tunnel and API Management as a thin gateway. Public Cloud needs none of it. Maesn reaches the released OData and SOAP APIs and does no orchestration on BTP.
SAP BTP subaccount
Needed for Private Edition and on-premise, where the Cloud Connector tunnel terminates. Not used for Public Cloud.
BTP API Management
The gateway Maesn calls for Private Edition and on-premise. A thin pass-through for the released OData and SOAP APIs, no transformation.
SAP Cloud Connector
Bridges those two to the customer's BTP. Free software that pairs with a BTP subaccount.
Direct endpoint exception
The exception for customers who keep BTP out: reaches Private Edition and on-premise without BTP.
If BTP is not in place yet
A BTP subaccount, the Cloud Connector pointed at it and the released APIs published through API Management. RISE customers usually have the entitlement already.
RISE customers usually have the BTP entitlement already. We go through it with your team before you start building.
Every SAP auth method, one account key
Authentication is where SAP integrations get specific, and it differs in every deployment. Maesn embeds each method behind unified authentication: your customer connects once and you receive one account key, with no SAP-specific branch in your code.
| Path | Mechanisms |
|---|---|
| Public Cloud | Communication Arrangement plus Communication User. Basic, X.509 client certificate and increasingly OAuth 2.0 (client credentials or SAML bearer) |
| Private / On-premise | Technical user (Basic), X.509 client certificates (STRUST + CERTRULE), OAuth via the SAP Gateway and principal propagation through the Cloud Connector |
| BTP layer | XSUAA / OAuth 2.0; destinations manage the credentials centrally |
On Public Cloud, Maesn registers a named Communication Scenario that appears under Maesn's name inside the customer's SAP, the standard SAP route with no custom protocol.
Customer connects
You send the customer into the flow. Maesn opens the connect step for their S/4HANA deployment. Which of the three they run is established there rather than asked of you.
Method and tunnel settled
Communication user, certificate, OAuth or Cloud Connector: Maesn resolves whichever applies and stores the connection. The SAP Basis work is done once, on our side.
One account key back
Every later request carries your API key plus that account key, identical across the whole catalogue. Your code does not learn which deployment is behind it.
The part worth being concrete about is who holds what. Communication users, X.509 certificates, OAuth clients and the Cloud Connector all live on the customer’s side of the line, and settling them is the work that normally needs an SAP Basis consultant on every single onboarding. Maesn does that once per connected customer and hands back a single value. Unified authentication carries a case here that no other system in the catalogue has: the method varies inside one product, so the same customer moving from on-premise to RISE changes how they are reached without changing anything you hold. The account key survives that move.
Changes, pushed as they happen
Most of an SAP integration is read and post on demand. For the changes that cannot wait, Maesn also carries events, so you react as they happen instead of polling.
Read and post on demand
OData and SOAP across all three deployments: you pull the data you need and post entries when your flow calls for it.
Pushed in near-real-time
Through SAP Event Mesh the system pushes changes as they happen, so a posting or a status change reaches your product without polling. Across all three deployments, with released events on Public Cloud.
Events arrive on the same footing as everywhere else in the catalogue, through one event model, so the handler you already wrote is the handler that receives them. What differs per system is what the system itself publishes, and that difference stays on our side of the connection.
Read and write, in one data model
Reads and writes run through Maesn's standard data model, the same objects you already use for the other systems in the catalogue. What SAP exposes depends on the deployment and the released scope.
From SAP into your product
From your product into SAP
Whatever you read comes back in the shared common data model, so a journal entry from an S/4HANA landscape has the same shape as one from a system a hundred times smaller, and the code you write here is the code you reuse for the next one.
What does not come out of the data model is the configuration: which account, which tax code and, in a group running several entities, which company code. Those values belong to the company, and Maesn reads the real ones from the live system so your customer assigns the accounts they recognise instead of a generic list. How that assignment is designed, and what it costs to maintain when a chart of accounts changes, is laid out in our guide to ERP configuration mapping.
Bring the object list your use case needs and the deployment your customer runs, and we will go through both on the call.
Certified, and we carry you there
Technology and certification are two separate decisions. The integration runs today over released APIs. When you want the certified, listed path, Maesn carries you through it, so your product arrives in the SAP Store under your own brand, not ours.
Maesn carries its customers through the certification and the listing, on top of the released-API integration.
SAP PartnerEdge
The build track for partners who ship integrations on SAP, and the entry to the official route.
Certified integration
“SAP Certified, Integration with SAP S/4HANA” on released APIs and a clean-core approach, exactly what SAP's certification looks for and exactly how Maesn builds.
Listed in the SAP Store
Under your brand, not Maesn's. The listing is the trust layer on top of the API, and it is the part an enterprise buyer looks for before a procurement conversation starts.
Why Maesn over a direct build
With SAP the build-or-buy question has an extra dimension, because there is no single thing to build. A Public Cloud tenant, a RISE landscape and an eight-year-old on-premise release are three target systems wearing one product name, and a customer can move between them while you are still their vendor.
One API across every variant
Public, Private and on-premise answer on the same interface. The deployment your customer runs stops being a project and becomes a setting, so a prospect on RISE and a prospect on an eight-year-old on-premise release reach you through the same onboarding.
Connectivity and auth stay ours
Cloud Connector, certificates, communication arrangements and principal propagation: the parts that need an SAP Basis consultant stay on Maesn's side, per connected customer. Your engineers never open a tunnel and never hold a certificate.
The next system costs nothing
Once SAP runs through Maesn, every other ERP and accounting system in the catalogue answers on the interface you already built. Nothing in this catalogue asks more of an integration than SAP does, so a team that has cleared it has cleared the hardest one first.
Public Cloud, Private Edition and on-premise on one REST API, with the connectivity and the authentication on our side.