API Proxy Creation

An API proxy is a managed façade in front of a real backend API. External callers never contact the SAP backend directly. They contact the proxy, which applies policies, validates requests, routes traffic, and then forwards the request to the backend. The backend's real URL, authentication mechanism, and internal structure remain hidden behind the proxy.

Think of a proxy like a company's main reception desk. Visitors do not wander into back offices to find the person they need. They check in at reception, state their purpose, get verified, and are escorted or directed appropriately. The API proxy is reception for your SAP APIs.

Types of APIs You Can Proxy

SAP S/4HANA OData APIs – The most common. Proxy the OData service URL to add security and throttling before external callers reach it.
CPI iFlow HTTPS endpoints – Proxy the CPI sender adapter URL so external apps go through API Management first.
On-premise SAP APIs – Through the Cloud Connector, proxy APIs exposed by on-premise SAP systems.
External third-party APIs – Proxy external APIs to centralize credential management and provide consistent monitoring across all API calls your organization makes.

Creating an API Proxy: Step by Step

Step 1: Access API Management

From the SAP Integration Suite home page, click Design, Develop, and Manage APIs. This opens the API Management capability. Navigate to Configure → APIs.

Step 2: Create New API

Click the + button to create a new API. You have two creation methods:

From URL – Enter the backend API URL directly. API Management reads the OpenAPI or WSDL specification from the URL automatically.
From API Business Hub – Select an SAP pre-defined API from the SAP API Business Hub catalog. The specification is pre-loaded.

Step 3: Configure Basic Details

API Name:     SalesOrderAPI
Title:        Sales Order Management API
Base Path:    /salesorders
API Base URL: https://your-s4hana.example.com
              /sap/opu/odata/sap/API_SALES_ORDER_SRV
Version:      v1
Description:  Exposes SAP S/4HANA Sales Order OData API
              for external partner applications

The Base Path is what external callers use. The API Base URL is the real backend URL. Callers hit your proxy at your API Management gateway URL + base path. The proxy forwards to the backend URL.

Step 4: Import API Specification

If the backend provides an OpenAPI (Swagger) specification or WSDL, import it. API Management reads the specification and automatically creates resource and operation definitions for each API endpoint, HTTP method, and parameter. This saves manual definition work and ensures the proxy accurately reflects the backend's capabilities.

Step 5: Configure Backend Authentication

The proxy must authenticate to the backend on behalf of callers. Configure the backend connection under the Target Endpoint settings:

URL – The real backend URL
Authentication – How the proxy authenticates to the backend (Basic, OAuth, Client Certificate)
Credential Store Reference – The alias from the API Management credential store

By storing backend credentials in the proxy, you remove the need to distribute backend credentials to all API consumers. Callers authenticate to the proxy — the proxy authenticates to the backend. Backend credential rotation requires updating only the proxy configuration, not every caller application.

Step 6: Save and Deploy

Click Save then Deploy. The proxy is now live. Test it using the built-in API Management test console or a REST client like Postman.

Proxy URL Structure

BEFORE API PROXY (direct backend call):
Caller URL: https://s4hana-prod.corp.com:44300
            /sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder
            (exposes internal server address and port)

AFTER API PROXY:
Caller URL: https://yourorg-api.cfapps.eu10.hana.ondemand.com
            /salesorders/A_SalesOrder
            (clean URL, no internal details exposed)

Virtual Hosts in API Management

API Management exposes your APIs through a Virtual Host — a custom domain URL that you configure on your API Management gateway. Instead of the default BTP domain URL, callers use a branded URL like api.yourcompany.com. Virtual host configuration requires DNS setup and TLS certificate upload in the API Management settings.

API Resources and Operations

After creating the proxy, define its resources (URL paths) and operations (HTTP methods). For an OData-based Sales Order proxy:

Resource: /A_SalesOrder
  GET    – List all sales orders (with optional filters)
  POST   – Create a new sales order

Resource: /A_SalesOrder({SalesOrder})
  GET    – Get specific sales order
  PATCH  – Update specific sales order
  DELETE – Delete specific sales order

Resource: /A_SalesOrder({SalesOrder})/to_Item
  GET    – Get line items of a specific sales order

Defining resources explicitly lets you apply different policies to different operations. For example, allow GET to all authenticated callers but restrict POST and PATCH to specific partner applications only.

Proxying a CPI iFlow

A common pattern wraps a CPI iFlow behind an API proxy:

External caller → [API Management Proxy] → [CPI iFlow] → [SAP Backend]
                   (security, throttling)  (transform)    (data)

The CPI iFlow's sender adapter exposes an HTTPS endpoint. The API proxy sits in front of that endpoint. External callers see only the clean proxy URL. The CPI endpoint URL, authentication, and internal structure are hidden.

This pattern provides full API lifecycle management for integration-based services — versioning, throttling, analytics, and developer portal discoverability — for services that are not simple API calls but complex multi-step integration flows.

Previous lesson

Back to course

Next lesson