Integrator for SAP
Integrating the SAP API into your system
We wire SAP S/4HANA into your B2B portal, ecommerce, or field app: the order creates the document, stock and ATP stay S/4's. One system for France and international.
- Senior product team
- ERP connectors in production
- scoping through to monitoring
Why work with a SAP integrator and what can be connected to SAP?
SAP is the reference ERP for large industrial and distribution companies, with S/4HANA at the core. You integrate it so your B2B portal, ecommerce or field app live on it: an order becomes a sales order, real ATP is shown, a single partner, without a parallel spreadsheet or a second system. S/4 stays the system of record; BTP serves the extension beside it, not a duplicate. Each SAP product exposes a different protocol: naming the product and scope at scoping is the first step.
What SAP changes in your platform
B2B portal that creates the S/4 order
The portal creates the sales order and reads ATP. The promised date is S/4's, not a middleware hope.
Ecommerce wired into stock and ATP
Customers, products and orders land in S/4. Price, credit and stock stay the ERP's logic, France and international.
Field app on the single partner
The app reads the Business Partner and open orders. Sales and warehouse see the same record, without triple entry.
Business approval outside SAP, same system
An order event goes to the approval workflow or business notification, without a fifteen-minute Excel batch.
What it changes in your product
Engineering in service of a measurable outcome: portal orders in S/4, real availability, a single partner.
S/4 stays the source of truth
Order, stock, price and credit stay in S/4. Your product attaches to it, it does not reimplement the ERP as a duplicate.
A delivery date you can keep
S/4 ATP (real availability) feeds the sales journey. You stop promising a date the warehouse refuses the next day.
One partner, not three records
The single Business Partner feeds CRM, billing and logistics. Reminders go to the right party, not a duplicate.
A connector that belongs to you
Code delivered, documented and maintainable. We work with your SAP team, without locking you into a black box.
How we wire SAP into your platform
Scoping
Where S/4 enters your product: portal, ecommerce, field. Public Cloud, Private or on-premises, open scenarios, BTP presence, middleware. Without that, an estimate means nothing.
Business mapping
Sales org, channel, division, order increment, credit block. Signed off with SD, FI or MM, not IT alone.
Development and testing
A connector wired into your portal, site or app. Only published Hub APIs, idempotency. Testing on the client QAS.
Monitoring
Failure alerts, retry queue, exchange log. You see an incident before it breaks the portal or the promised date.
What the API brings to your platform
- Create the order from the portal
- Published Hub APIs: sales order, Business Partner, product. Published services only, never an internal Fiori endpoint.
- Activate inbound access before the first flow
- Without an active Arrangement (communication system + technical user), the endpoint does not exist for you, even if it appears on the Hub.
- React in the product without a batch
- S/4 events pushed to Event Mesh (order created, for example). This is not a webhook URL to paste into a screen.
- Extend beside S/4, not inside it
- BTP side-by-side: Destinations, Integration Suite, CAP. The specific layer lives outside the core, so a release does not break a Z-program.
The vocabulary of an SAP integration
- Communication Arrangement
- The inbound access contract in Communication Management: system, technical user, SAP_COM_* scenario. Without it, Hub OData is not reachable from outside.
- Communication User
- A technical account, not a named user. Rotation, vault, one user per environment (DEV, QAS, PROD). Inbound Basic Auth remains common on Public Cloud.
- Business Accelerator Hub
- The catalogue of published APIs (formerly API Business Hub). We only consume what is listed for the package and tenant version, metadata frozen in the repository.
- BTP
- Business Technology Platform: Destinations, Integration Suite, CAP, Event Mesh. It is not S/4. A page that says « SAP API » while talking about BTP mixes the ERP and the extension.
- Event Mesh
- The BTP event bus that receives S/4 Event Objects. Your app subscribes here. There is no S/4 screen where you paste a HubSpot-style HTTPS URL.
- API Policy
- SAP's rule: Published APIs only. Calling an internal endpoint, scraping Fiori or extracting outside intended paths is forbidden. Reverse-engineering is not a deliverable.
The real constraints of an SAP integration
« SAP » names several products
S/4HANA Cloud Public, Private / on-premises, BTP, Business One and ECC share neither protocol nor contract. The first deliverable is to name the product, or the estimate means nothing.
No Arrangement, no inbound API
On Public Cloud, without an active Communication Arrangement, the OData endpoint does not exist for you, even if it is on the Hub. Activation is an SAP workstream, not an HTTP header.
Published Hub APIs only, nothing else
The API Policy forbids internal endpoints and Fiori scraping. We only ship Hub services, versioned, for your tenant's package. Unpublished paths are out of scope.
S/4 OData is not a flat REST resource
Deep insert, $filter, $expand, $batch, ETags, sometimes SOAP in parallel. Mapping a sales order (items, partners, conditions, texts) is a project, not fifteen fields.
S/4HANA Cloud or BTP, and what it implies
Two distinct layers. S/4 is the ERP. BTP is the extension platform. Mixing them in a quote makes the project unpriceable.
| Criterion | S/4HANA CloudThe ERP, published APIs | SAP BTPExtension, not the ERP |
|---|---|---|
| Role | ERP core: partner, order, stock, FI | Side-by-side: UX, flows, public API, AI |
| Access channel | Hub OData V2/V4 and SOAP, Arrangement | Destinations, Integration Suite, CAP, Event Mesh |
| Authentication | Communication User, OAuth 2.0, certificate | Auth to S/4 via Destination (Basic, OAuth, certificate) |
| Real time | S/4 Event Objects (hundreds on Public Cloud) | Event Mesh subscription, then your application |
| Quotas | Per-API controls on the Hub, no public global figure | Those of the subscribed BTP service, distinct from S/4 |
| Integration effort | High: SD/FI/MM mapping and Arrangement | High if the specific lives there, lighter as a plain Destination |
| The right case | A portal or storefront that creates the document in S/4 | A process missing from the core, isolated from release upgrades |
We claim no SAP partnership, and no BTP or Integration Suite certification. We integrate through the published APIs of the Business Accelerator Hub, with the client's SAP team or incumbent integrator.
What we measure on an SAP project
The other ERPs we integrate
The choice follows whichever ERP you already run, rarely the technology.
We combine SAP with
The stack that surrounds S/4 and BTP on our projects.
SAP integration: your questions
First map where S/4 enters your product (portal, ecommerce, field) and name the product: S/4HANA Cloud Public, Private / on-premises, BTP, Business One or ECC. On Public Cloud, inbound access requires an Arrangement and a communication user. We only consume published Hub APIs. Idempotency rests on the S/4 document number. BTP comes in if the specific layer must live outside the core. The real difficulty is not the HTTP call, it is that the channel order and the ATP shown share the same S/4 truth.
It depends on the product, the touchpoints and the business mapping. A portal that creates sales orders is priced differently from an ecommerce bridge covering catalogue, orders and returns, or from a BTP extension. Two things weigh heavily: Communication Scenarios already open, and middleware already in place. An ECC landscape is not the same quote as a Public Cloud tenant. We scope the product and give a firm estimate.
S/4HANA Cloud is the ERP: partner, order, stock, finance. Its APIs are the Hub's, behind a Communication Arrangement. BTP is the extension platform: Destinations to S/4, Integration Suite for flows, CAP for a business process missing from the core, Event Mesh for events. A BTP app does not « hit » S/4 hardcoded: it goes through a named Destination. Mixing the two in a brief produces a false quote. Scoping decides: document in S/4, specific beside it, or both.
Partner status is useful for the functional rollout, licences and S/4 configuration. For a connector on the public APIs, what counts is command of OData, Arrangements and the business mapping, plus the ability to work with the SAP team already in place. We claim no SAP partnership and no BTP certification: we build on the published APIs of the Business Accelerator Hub, and we are glad to work with the incumbent integrator who runs your core.
No. The SAP API Policy only allows Published APIs from the Hub for the package and tenant version. Reverse-engineering a Fiori screen, an internal namespace or a bulk extract outside intended paths is not a deliverable integration. On Public Cloud, even a Hub service stays unreachable until the Arrangement is active. We freeze the service name, OData version and metadata in the repository, and we test on the client's QAS: the Hub sandbox has neither your extensions nor your business checks.
An SAP integration to discuss?
Let's talk. 30 minutes to identify where S/4 touches your portal or channel, the product (S/4 Cloud, BTP, ECC), the scenarios already open, then tell you honestly what is feasible.
Discuss my SAP project