# SAP Integration: The Complete 2026 Guide to Methods, Tools, and Patterns

SAP integration is how you connect SAP systems like S/4HANA, ECC, and SuccessFactors to other applications and data. It works through classic interfaces (IDoc, BAPI/RFC, and OData/REST APIs) and through SAP Integration Suite, SAP's cloud iPaaS on Business Technology Platform. Which method you pick depends on whether you need real-time APIs, document-based EDI, or managed cloud integration flows. This guide maps each one to a use case.

Ask two SAP architects how to integrate a system and you'll get three answers, because SAP has accumulated integration methods for thirty years and never fully retired any of them. An IDoc interface written in 2005 still runs in production next to a REST API released last quarter. Building one SAP interface is straightforward. The real work is choosing which of the roughly six methods fits the job in front of you.

I've spent the better part of a decade on the Salesforce side of integrations like these, first at Zennify and Salesforce, now at appnigma. The pattern holds on both ends of the wire: the tool matters less than matching the method to the latency, volume, and direction you actually need. Get that match wrong and no amount of platform licensing saves you.

SAP integration connects the SAP core (your ERP plus line-of-business apps like SuccessFactors for HR or Ariba for procurement) to everything outside it: CRMs, ecommerce storefronts, data warehouses, trading partners, and custom apps. The goal is that a fact entered once (a customer, an order, a price) stays consistent everywhere it needs to live.

Two broad families do the work.

1. Classic interfaces built into the ABAP stack: IDoc, BAPI/RFC, and OData services. These live inside SAP and expose its data and business functions directly.

2. The managed platform, SAP Integration Suite, which sits on Business Technology Platform (BTP) and orchestrates flows between SAP and non-SAP systems with mapping, monitoring, and connectors.

Most real landscapes use both. A high-volume order feed might run on IDocs while a new customer-facing app reads master data over OData, and Integration Suite sits in the middle for the flows that need conversion and monitoring. For a broader primer on how integration styles compare, our guide to the four types of integration covers the fundamentals that apply here.

These three are the backbone. Knowing when each fits is most of the battle.

IDoc (Intermediate Document) is document-based and asynchronous. Think of it as a structured envelope for a business document: an order, an invoice, a material master record. IDocs use standard message types (ORDERS, INVOIC, MATMAS) and are the historical backbone of EDI and master-data distribution in SAP. They shine for high-volume, batch-friendly flows where guaranteed delivery matters more than instant response.

BAPI/RFC is function-based and usually synchronous. RFC (Remote Function Call) is the protocol; a BAPI (Business API) is a standardized, released function you call to read or write an SAP business object. If you need to create a sales order in real time and get the order number back, a BAPI call does it. The trade-off is coupling: RFC is an SAP-proprietary protocol, so consumers need an SAP-aware connector.

OData/REST is the modern layer, especially on S/4HANA. OData services expose SAP data as RESTful endpoints over HTTP, returning JSON or XML that any web, mobile, or cloud client can read without an SAP-specific library. For new builds, this is usually where teams start, because it removes the connector friction that RFC carries.

The honest reason most new integrations reach for OData over RFC has little to do with elegance. It is that a web developer can consume an OData endpoint on day one, while RFC needs SAP middleware and someone who knows it. When you are staffing a project, that difference decides timelines.

Source: SAP Business Accelerator Hub and appnigma integration practice, 2026.

When you have more than one interface and more than two systems, you want a place to build, run, and watch all of it. That place is SAP Integration Suite, SAP's integration-platform-as-a-service on BTP, documented in full on the SAP Help Portal. It bundles several capabilities you enable as needed. Our deep dive on SAP Integration Suite unpacks each one; the short version:

1. Cloud Integration (formerly CPI) builds and runs integration flows (iFlows) that move and convert messages between systems. This is the core middleware capability. The SAP CPI guide walks through how an iFlow actually works.

2. API Management publishes, secures, and monitors APIs by wrapping backends in proxies with policies for authentication and rate limiting.

3. Open Connectors provides pre-built connectors to hundreds of non-SAP applications, so you are not hand-coding every third-party link.

4. Event Mesh handles event-driven integration, letting systems react to business events instead of polling for changes.

For B2B and EDI, Integration Suite adds Trading Partner Management and Integration Advisor, which translate partner document formats into SAP structures. That path gets its own treatment in the SAP EDI integration guide.

The reason to adopt the suite is not that it is technically superior to a clean point-to-point call. It is that centralized monitoring, retries, and error handling stop being your problem to hand-build. When a flow fails at 2 a.m., you want a dead-letter queue and an alert, not a silent gap discovered a week later.

Where your SAP system runs changes which interfaces you even have.

On-prem ECC gives you the full classic toolkit: RFC, IDoc, custom function modules, direct database-level tricks that people probably should not use but do. Maximum flexibility, maximum responsibility.

S/4HANA Cloud (public edition) deliberately restricts that freedom. You integrate through released, whitelisted APIs (mostly OData and SOAP) and approved extensibility points. You cannot reach into arbitrary function modules the way you could on ECC.

Hybrid landscapes bridge the two with the SAP Cloud Connector, which lets cloud services reach on-prem systems through a controlled tunnel.

Here is the gotcha that catches migration projects. An interface that worked fine on ECC through a custom RFC may have no released equivalent on S/4HANA Cloud. Teams discover this mid-migration and have to redesign the integration around whatever released API exists, or file for a new one. Check released-API availability before you assume a lift-and-shift, not after. We cover the ERP-specific version of this in the SAP ERP integration guide.

Beyond picking an interface, you pick a shape for the flow, and three axes decide that shape.

Synchronous vs. asynchronous. A synchronous call waits for a response: you request a sales order and get the order number back before moving on. Asynchronous flows hand the message to a queue and trust it to deliver. Synchronous suits real-time reads and user-facing writes. Asynchronous suits high volume and anything where the receiver might be slow or briefly down, because the message waits instead of failing.

Batch vs. real-time. Batch collects records and moves them on a schedule, which is cheap and forgiving for master data that changes hourly. Real-time moves each record as it happens, which the business wants for inventory and order status but which costs more to run and watch. Match the cadence to how fast the data actually changes, not to how fresh it would be nice to have.

Event-driven. Instead of one system polling another for changes, the source publishes a business event, an order created or a delivery shipped, and interested systems react. SAP Event Mesh carries these events. This removes the constant polling that quietly burns API quota, and it scales better when many systems care about the same change.

The mistake is defaulting everything to real-time synchronous because it sounds better. That couples systems tightly and multiplies load. Reserve synchronous for the flows a person is waiting on, and let the rest run asynchronous or event-driven.

An SAP integration is a door into your most sensitive data, so authentication is not something you bolt on later.

OAuth 2.0 is the standard for modern SAP APIs and Integration Suite, with services authenticating through tokens and scopes rather than stored passwords, and BTP acting as the authorization server for cloud flows. Token lifetime, scope minimization, and rotation are the same discipline here as on the Salesforce side.

Principal propagation carries the real end user's identity from a cloud app through to the on-prem SAP system, so authorizations and audit trails stay tied to a person instead of a shared technical user. It is more setup than a single service account, and it is the right call whenever per-user authorization or auditability matters.

SAP Cloud Connector is the controlled tunnel for hybrid landscapes. It sits in your network, opens an outbound connection to BTP, and exposes only the on-prem resources you whitelist, with nothing inbound opened.

The recurring failure is the shared technical user with broad authorizations and a password that never rotates. It works on day one and becomes the finding in your next security review. Scope every integration user to exactly what its flow needs.

The difference between an integration that runs for years and one that quietly rots is what happens when a message fails.

Monitoring means every flow reports its status somewhere you actually watch. Integration Suite gives message monitoring out of the box, and classic IDoc processing has status codes and transaction-level monitoring. Either way, something has to be watching, because a failed sync with no alert is an outage you hear about from an angry customer first.

Error handling decides what a flow does when a call fails: retry with backoff for transient errors, route to a dead-letter store for messages that need a human, and never let one bad record silently halt a batch of thousands.

Reprocessing is the recovery step people forget. When a downstream system was down for an hour, you need a clean way to replay the messages it missed. IDocs can be reprocessed from their stored status, and Integration Suite supports retry and stored message replay. Without a reprocessing story, your recovery plan is manual data entry.

The build cost of an SAP integration is visible. The run cost is the one that surprises people.

Integration Suite on BTP is priced by consumption and tier, and the capabilities you enable factor into the bill. A proof of concept that fits a low tier can cross into a very different number at production message volume, so model real throughput before committing. Third-party iPaaS like MuleSoft and Boomi carry their own licensing, often per connection or volume, so compare run cost at your actual volume, not the entry-tier sticker price.

Licensing rarely decides the architecture, but it belongs in the room early. The cheapest platform to build on is not always the cheapest to operate.

Most SAP integration work falls into a handful of recurring shapes.

SAP and CRM. Connecting SAP to a CRM like Salesforce means syncing the customer master and running the order-to-cash handoff, where a closed deal becomes an SAP sales order and billing status flows back. This is one of the most common and most argued-over integrations, and it has its own full breakdown in Salesforce and SAP integration.

SAP and ecommerce. A storefront needs product, price, and inventory from SAP, and pushes orders back. Inventory latency is the metric that makes or breaks it, because a stale stock number means overselling.

SAP and trading partners (EDI). Purchase orders, invoices, and ship notices exchanged with suppliers and customers, historically through IDocs, now increasingly through Trading Partner Management in Integration Suite.

SAP and analytics. Getting SAP data into a warehouse or lake for reporting, either by replicating it or querying it in place. The replicate-versus-federate decision drives the design here.

Each of these has a different right answer for method and tooling, which is exactly why "how do I integrate SAP" has no single response.

SAP Integration Suite is not the only middleware option, and plenty of SAP landscapes run on tools SAP did not build.

MuleSoft, owned by Salesforce, ships SAP and S/4HANA connectors and appeals to teams whose center of gravity is already Salesforce and who want the integration logic on that side. Boomi and other iPaaS vendors compete on the same ground, with pre-built SAP connectors and visual flow builders.

The choice is rarely about raw capability, because the major platforms all move SAP data competently. It comes down to where your team already has skills, where the rest of your landscape lives, and how much of the integration you want SAP to own versus a neutral third party. A shop that runs SAP end to end usually standardizes on Integration Suite for support and licensing reasons. A shop where SAP is one system among many, with Salesforce or a data platform at the core, often lands on a vendor-neutral iPaaS instead.

The pattern that consistently goes wrong is the third path: skipping middleware entirely and wiring point-to-point calls by hand. One direct API call is clean. Seven of them, each with its own retry logic and credentials, become a maintenance liability nobody owns. That sprawl has a real cost, which we broke down in the hidden costs of glue code. The lesson transfers directly to SAP.

A short list of the failures that show up again and again:

1. Assuming an ECC interface exists on S/4HANA Cloud. Check released-API availability first. Redesigning mid-migration is expensive and avoidable.

2. Syncing everything bidirectionally. Decide system of record per object. Two-way sync on a field only one system should own creates conflicts, not consistency.

3. No monitoring plan. An integration without alerting is a silent outage waiting to happen. Guaranteed delivery and error visibility are design requirements, not afterthoughts.

4. Under-scoping the interface count. Teams price a project for four interfaces and discover eleven. Count master data, transactional, and status-return flows separately before you commit.

A decision path that holds up across projects:

1. Start with latency. Real-time reads and writes point you at OData or BAPI/RFC. Document-based, batch, or EDI flows point you at IDoc.

2. Weigh volume and the cost of failure. High volume with a real need for guaranteed delivery and monitoring justifies SAP Integration Suite. A single low-stakes feed does not.

3. Settle direction and system of record. Decide which system owns each object before you build. A perfectly bidirectional sync between two systems that disagree about the customer is just a faster argument.

4. Count the systems. Two systems and one interface can run point-to-point. A landscape with several systems and many interfaces wants the central platform, both for reuse and for the monitoring you will otherwise rebuild by hand.

If you are weighing a managed platform against direct, native connections, our comparison of native integration vs. iPaaS lays out where each earns its cost, and the same logic transfers cleanly to the SAP side.

What is SAP integration? SAP integration is the practice of connecting SAP systems (such as S/4HANA, ECC, or SuccessFactors) to other applications and data sources so information stays consistent across them. It happens through classic SAP interfaces (IDoc, BAPI/RFC, and OData/REST APIs) and through SAP Integration Suite, SAP's cloud integration platform on Business Technology Platform.

What are the main SAP integration methods? The core methods are IDoc for document-based asynchronous flows, BAPI/RFC for synchronous function calls into SAP business objects, and OData/REST for modern API access, especially on S/4HANA. On top of these, SAP Integration Suite provides managed integration flows, API management, pre-built connectors, and event-driven messaging.

What is SAP Integration Suite? SAP Integration Suite is SAP's integration-platform-as-a-service, delivered on SAP Business Technology Platform. It bundles capabilities including Cloud Integration (formerly CPI) for integration flows, API Management, Open Connectors, Event Mesh, and Trading Partner Management for B2B and EDI. You enable the capabilities you need rather than adopting all of them at once.

IDoc vs. BAPI vs. OData, when to use each? Use IDoc for high-volume, document-based, asynchronous flows like EDI and master-data distribution. Use BAPI/RFC when you need synchronous, real-time reads or writes into SAP business objects. Use OData/REST for new cloud, web, and mobile builds where standard HTTP and JSON remove the need for SAP-specific connectors.

Is SAP integration real-time? It can be either. OData/REST and BAPI/RFC support real-time, synchronous exchange, so a request gets an immediate response. IDoc-based integration is asynchronous and better suited to batch or document flows where guaranteed delivery matters more than instant response. Most landscapes mix both depending on the scenario.

How do you secure an SAP integration? Modern SAP integrations authenticate with OAuth 2.0 tokens and scopes rather than stored passwords, with BTP acting as the authorization server for cloud flows. For hybrid landscapes, the SAP Cloud Connector exposes only whitelisted on-prem resources through an outbound tunnel, and principal propagation keeps the end user's identity intact for authorization and auditing. Scope every integration user to exactly what its flow needs.

How much does SAP integration cost? It depends on the method and, more importantly, the run volume. SAP Integration Suite on BTP is priced by consumption and tier, so a low-volume proof of concept can cost far less than a production system moving high message volume. Third-party platforms like MuleSoft and Boomi carry separate licensing, often per connection or volume. Model your real throughput before committing, because run cost, not build cost, is what surprises teams.

About the author. Sunny Chauhan is the founder of appnigma.ai, where we build native Salesforce apps and integrations without glue code: direct, observable connections instead of a stack of hand-maintained callouts. He's a Salesforce-certified Platform Developer II who spent the better part of a decade building integrations and managed packages, including work at Zennify and Salesforce, before founding appnigma. That's why the method-fit question, not the tool, is where every integration conversation here starts.

If you're mapping an SAP integration right now, which comes first for you: the latency you need, or the system that gets to own the record?