First, we will place API Management inside SAP Integration Suite and SAP Business Technology Platform (BTP). Then we will walk through each capability of Integration Suite, one by one, so you know what each tool is for.

SAP BTP, SAP Integration Suite, and API Management

SAP API Management is one capability inside a larger product called SAP Integration Suite. SAP Integration Suite is SAP’s integration platform as a service (iPaaS), and it runs on SAP Business Technology Platform (BTP). So when someone says “APIM on BTP,” what they actually mean is the API Management capability of Integration Suite, running in a BTP subaccount.

SAP API Management is one capability of SAP Integration Suite, which is SAP’s iPaaS running on SAP BTP.

I find it helpful to think of Integration Suite as a toolbox. Different integration problems call for different tools, and each tool in the box is what SAP calls a capability.

You activate only the capabilities you need in your Integration Suite tenant, so two companies running “Integration Suite” can be using very different parts of it.

The Capabilities of SAP Integration Suite

Let’s go through the toolbox. I have grouped these the way I think about them in practice: the core capabilities you will touch on in each and every project, and then the rest of the toolbox, which is more specialized.

Core Capabilities

1. Cloud Integration (CI) - Former Product CPI

Cloud Integration, which almost everyone still calls CPI, is the core engine of the suite and by far the most commonly used capability. This is where you build integration flows (iFlows) that move data between systems: mapping fields, transforming formats, and routing messages. If System A needs to send an invoice to System B and the formats don’t match, the iFlow that bridges them is built here.

If you are coming from SAP PI/PO, Cloud Integration is the closest thing to what you already know. This is one of the most widely used capabilities in SAP Integration Suite; I have always used SAP CI in every SAP S/4HANA implementation project where the integration platform was SAP Integration Suite.

2. API Management

API Management is the capability this entire series of articles is about. It sits as a governance and security layer in front of your APIs. It controls who can call an API, how often they can call it, and what happens to the request and response on the way through. It also gives API consumers a place to discover and subscribe to your APIs. We will go much deeper into each of these in the upcoming articles.

3. Event Mesh

Event Mesh handles event-driven communication. A system that needs to know about a business event (business document change) typically polls another system over and over, asking “has anything changed yet?” Or the sender system having to push the data to each and every receiver system.

With Event Mesh, the source system publishes the business event instead, for example, “a sales order was created,” and any interested system subscribes to that event and reacts in real time.

The result is communication that is decoupled and asynchronous.

4. Open Connectors

Open Connectors gives you prebuilt connectors to third-party cloud applications such as Salesforce, Slack, and Dropbox. SAP currently lists more than 160 of them. The useful part is that they all sit behind one unified REST API, so instead of learning each vendor’s authentication model, pagination style, and error format, you connect to all of them in one consistent way.

The Rest of the Toolbox (Capabilities)

5. Trading Partner Management and 6. Integration Advisor

I like to think of these two as the B2B EDI integration tools. They are usually used together.

Trading Partner Management (TPM) handles Electronic Data Interchange (EDI) communication with your business partners: storing partner profiles, agreements, and the technical details of how you exchange documents with each one. Integration Advisor uses machine learning to help you build message implementation guidelines and mappings for B2B standards such as UN/EDIFACT and ASC X12.

However, my experience is that Integration Advisor helps to build mappings between EDI formats and iDocs for EDI integration with SAP S4 HANA. How you build mappings is a little bit different to the tradition message graphical message mapping. Hence, there is a bit of a learning curve to use it.

However, if your company exchanges orders, invoices, or delivery notes with external partners over EDI, these two capabilities can come in handy.

7. Integration Assessment

Integration Assessment is a planning tool. Before you build anything, it helps you evaluate your integration landscape and recommends which integration technology fits each scenario. It is a decision support tool for architects and integration consultants.

8. Migration Assessment

Migration Assessment is aimed specifically at organizations moving from SAP Process Orchestration (PI/PO) to Integration Suite. It analyzes your existing PI/PO interfaces and tells you which ones can migrate easily, which need manual work, and roughly how much effort to expect.

9. Graph

Graph is actually part of the API Management capability rather than a separate tool. It connects your SAP landscape into a single, unified API with a semantic data layer on top. So instead of a consuming application calling a dozen different endpoints across different SAP systems, it queries one endpoint and gets the business data it needs.

10. Edge Integration Cell

Edge Integration Cell is a hybrid deployment option. It lets you run the integration runtime inside your own private infrastructure, on a Kubernetes cluster you manage, while design, management, and monitoring still happen from the cloud. This matters for companies that have strict data residency or security requirements and cannot let certain messages leave their own network.

Alongside these ten, SAP’s own capability list also includes a few smaller ones, such as OData Provisioning and Data Space Integration. You won’t need them for this course, but it is good to know they exist when you browse the capability list in your tenant.

Which Capability Solves Which Problem?

Here is the rule of thumb I use when someone asks me, “which part of Integration Suite do I need?”

• Move and transform data between two systems: Cloud Integration (CI)

• Secure, throttle, and publish APIs for consumers: API Management

• Notify many systems when something happens, in real time: Event Mesh

• Connect to third-party SaaS apps in a simple way: Open Connectors

• Exchange EDI documents with business partners: Trading Partner Management + Integration Advisor + CI

• Decide which integration technology to use: Integration Assessment

• Plan a move from SAP PI/PO: Migration Assessment

• Expose many SAP systems through one business-data API: Graph (part of API Management)

• Keep the runtime inside your own network (On-premise): Edge Integration Cell

In real projects, these capabilities are rarely used in isolation. A very common pattern, and one we will discuss in a future article, is an iFlow in Cloud Integration that does the heavy lifting, with API Management sitting in front of it to secure and control who can call it.

Where API Management Fits

So, to bring it together: SAP Integration Suite gives you all of these capabilities under one toolbox, and API Management is the one we focus on in this series of articles. It sits alongside Cloud Integration, Event Mesh, and the others as the governance and consumer-experience layer for your APIs.

Cloud Integration answers the question “how do I connect these systems?”

API Management answers a different one: “now that this API exists, who is allowed to use it, how much, and how do they find it?”

In the next article, we will zoom in on API Management itself and look at what it actually does, the core functions it provides.

If you have any questions about the capabilities of SAP Integration Suite or where API Management fits, please leave a comment below. I will be happy to help.

What Is an API Proxy?

Let’s start with the concept, because it’s worth slowing down on this before touching the API Portal.

Say your backend is a service sitting at a real, callable address.

For this article, we’ll use a free exchange-rate API at https://open.er-api.com/v6/latest. If you called that URL right now, it would hand you back the latest currency exchange rates.

If we let every client app call that address directly, we have a problem: once a client knows your backend’s real address, you’ve lost control over who can call it, how often they can call it, and what they can do once they’re in.

So instead of exposing the backend itself, we put something in front of it.

That something is called an API proxy.

An API proxy is a facade for your APIs that you build and deploy in SAP API Management. The client app never talks to your actual API backend. It talks to the proxy, and the proxy forwards that call to the real backend on the client’s behalf.

Here’s an analogy for an API Proxy: think of a hotel front desk.

If you want to contact someone staying at the hotel, you never call a guest’s room directly, and you don’t even know the room’s extension number. Instead, every call goes through one number - the hotel’s front desk. You dial the front desk, the person at the desk figures out who you’re trying to reach, and connects you through internally. The guest never has to publish their extension to the outside world, and the hotel can move that guest to a different room tomorrow without anyone outside ever noticing, because the number you dial never changes.

The API proxy is that front desk. The backend system is the guest’s room. The client app is you, calling in from outside.

API Proxy URL vs. Target API URL

This is the part that trips up most people new to SAP APIM, so it’s worth being explicit about it.

🛑 Key distinction

The Target API URL is your backend’s real address - the room extension. The API Proxy URL is a brand new, published address that SAP API Management generates once you deploy the proxy - the front-desk number. Clients only ever call the API Proxy URL.

The Target API URL, in our case, is https://open.er-api.com/v6/latest. This address lives inside the proxy’s target configuration and is never given out to client apps.

The API Proxy URL is generated by SAP API Management once you deploy, something like:

https://3ed7f623trial-trial.integrationsuitetrial-apim.us10.hana.ondemand.com/3ed7f623trial/v1/exchangerates

This is the only address you ever hand to a client. Nobody outside needs to know, or should know, that open.er-api.com exists at all and know that is where the actual exchange rates are extracted.

Why Use the APIM (Proxy) Layer?

Three reasons, each mapping back to the hotel front desk:

• Decoupling. The hotel can move a guest to a different room, or even a different floor, and the number you dial never changes. If you later move your backend, or swap the exchange-rate provider entirely, the client’s API Proxy URL doesn’t change - you just update where the proxy points internally.

• Control. Every call is forced through the front desk - there’s no side door. This is the checkpoint where you attach policies like Verify API Key, Spike Arrest (protection againist bots), and Quota. None of that logic sits on the backend; it all sits at the proxy.

• Transformation. A front desk doesn’t just connect a call - it can take a message and pass it along in a cleaner form. A proxy can reshape the request before it reaches the backend, or reshape the response before it goes back to the client, without the backend ever needing to change.

Every API proxy has two sides: the ProxyEndpoint, which faces the client (the published front-desk number), and the TargetEndpoint, which faces your backend (the real room extension). We’ll go deeper on both of these in a later article - for now, just remember which side does what.

Demo Scenario Overview

For this walkthrough, we’ll wrap the same exchange-rate backend we just discussed:

• Target API URL: https://open.er-api.com/v6/latest

It’s a free, no-auth API, which makes it a good first target. There’s no credential handling to worry about yet, so we can focus entirely on the proxy mechanics.

Step 1: Create the API Proxy

Log in to the SAP API Portal and go to the Configure area. This is where all your API proxies live.

Click Create under the API Proxy tab. A wizard opens asking for some basic details.

Give it a name. Since this proxy wraps the exchange-rate backend, let’s name it exchangerates.

Below the name, set the base path. This is the part of the URL clients will use to reach the proxy once it’s deployed, effectively the front-desk number.

Set the API base path to /exchangerates.

Subscribe now

It is recommended to structure your API resources with a version ID. Therefore, let’s add the version as v1. If the version is configured, the base path of the API proxy will be automatically changed to reflect the version: /v1/exchangerates.

Step 2: Configure the Target Endpoint

Move to the next step, where you configure where the proxy should actually forward requests. Paste in the target URL: https://open.er-api.com/v6/latest.

This is the private room extension, or the backend service URL - the client will never see this address directly

We will select the target type as “URL” since the target API we configure is a pure URL.

Click Create, and you’ll see a summary of everything configured: the name exchangerates, the base path /v1/exchangerates, and the target URL https://open.er-api.com/v6/latest.

Click Save.

At this point, the API proxy has been created but it isn’t live yet. It will be in “Un Deployed” status. Creating the proxy only saves its configuration and proxy URL.

Step 3: Deploy the API Proxy

To make the proxy callable, you need to deploy it.

Click Deploy.

Wait for the deployment to finish. Once the status changes to Deployed, the proxy is live and reachable at its own published URL.

The API Proxy URL for trial accounts will be in this format:

https://<subaccount-id>–trial.integrationsuitetrial-apim.<region>.hana.ondemand.com/<subaccount-id>/<your-API-proxy-base-path>

That’s your front-desk number now. Nobody calling this URL needs to know that open.er-api.com exists behind it.

Testing the API Proxy

Grab the deployed proxy URL and open it in a new browser tab, or trigger it via Postman.

The response comes back with the latest exchange rates, exactly what the backend would have returned if called directly.

Nothing has been added or removed, because no policies have been attached yet. Right now, the proxy is doing exactly one thing: receiving the client’s request and passing it straight through to the backend, then passing the response from the backend straight back to the caller.

Notice the response from the backend you saw before - it should be identical to the proxy response. The same data, same structure, nothing lost in between.

That’s exactly what you want to confirm at this stage, before adding any logic on top.

Now you can add your policies on top of it. We will look at how to add policies in another article.

Tips and Tricks

• Keep the very first version of any proxy a bare pass-through, like we did here, before attaching any policies. It gives you a baseline to compare against once you start adding Verify API Key, Spike Arrest, or transformation policies. If something breaks later, you’ll know it’s the policy, not the underlying proxy configuration.

• Double-check the base path doesn’t collide with an existing proxy on the same environment. Since the base path is what routes incoming calls to the correct proxy, an overlapping path will cause deployment or routing issues.

This bare pass-through proxy is your starting point. In upcoming lessons, we’ll start attaching policies to it, and this is exactly where the ProxyEndpoint and TargetEndpoint structure we introduced above comes into play.

If you have any questions about creating or deploying your first API proxy in SAP API Management, leave a comment on the original post. I’ll be happy to help.

Full online course

Rather watch the lesson in video format?

Cloud Integration with SAP Integration Suite for Beginners — 200+ video lessons, direct support from me if you get stuck, no prior SAP experience needed.

See the full curriculum →