API Management and Principal Propagation Explained

API Management is the proxy/gateway layer in SAP Integration Suite that sits in front of APIs to apply security, throttling and analytics without touching the backend implementation. Principal propagation is a related but distinct mechanism: it forwards the identity of the real end user from a cloud caller through to an on-premise ABAP or non-SAP backend, instead of collapsing every request onto one shared technical communication user. The structural fact that causes most confusion: API Management authenticates the caller to the proxy using an API key or OAuth token, while principal propagation authenticates the original human user all the way through to the backend using a short-lived X.509 certificate issued via Cloud Connector. These are two separate trust chains. A setup that works perfectly in Postman with an API key can still fail for a real Fiori user because the certificate-based identity chain behind principal propagation was never configured or trusted.

Reach for API Management when exposing APIs to external partners, mobile clients or third-party consumers, when rate limiting, quota, API key or OAuth enforcement is needed, when analytics on consumption matter, or when backend endpoints need to be versioned or masked behind a stable contract. It is not needed for simple internal point-to-point integration where an iflow can call the backend directly. Reach for principal propagation when backend authorization decisions must reflect the actual end user - ABAP authority checks, CDS access control, audit trails that must show a real person, not a service account. It is a mistake to default to principal propagation everywhere: it adds certificate infrastructure, latency and a harder troubleshooting surface. If the backend only needs to know 'this call came from an authorized system', a technical user with scoped OAuth client credentials is simpler and more resilient.

Above API Management sits the API consumer - an external partner app, a mobile client, or a Fiori app reached through the app router. Below it sits the actual service: a Cloud Integration iflow, an S/4HANA OData service, or a custom backend API. API Management does not replace Cloud Integration; it complements it, often fronting iflows or backend services with a stable, governed contract. It supersedes ad hoc reverse proxies and custom gateway code that landscapes used to build by hand. Principal propagation sits orthogonally, in the connectivity layer between a BTP application or CPI and an on-premise system, built on the Destination service and Cloud Connector's reverse-invoke tunnel. It supersedes older, manually assembled SAML2 application-to-application SSO configurations that had to be wired per scenario before Cloud Connector offered this as a configuration option.

A partner-facing procurement app calls a BTP-exposed API to fetch purchase order status. The API proxy in API Management enforces an API key check and a spike arrest policy, then routes the call to a Cloud Integration iflow that talks to the backend. Separately, inside the same subaccount, a Fiori app shows a manager their own approval worklist sourced from an on-premise ECC system reached through Cloud Connector. The destination pointing to that system is configured with authentication set to principal propagation. Cloud Connector has the corresponding system mapping enabled for principal propagation, and its certificate has been imported into the ABAP system's trust store via the trust manager, with a certificate rule mapping the certificate subject to the ABAP user ID. When the manager opens the launchpad, BTP issues a short-lived client certificate carrying the manager's identity, the destination service presents it at the connectivity boundary, Cloud Connector forwards it, and the ICM on the ABAP side authenticates the manager directly. Authority checks in the backend then run under the manager's own user, not a generic RFC service user, and the audit log shows the real actor.

In a clean-core S/4HANA target state, API Management is the recommended way to expose extension APIs and partner-facing endpoints without opening bespoke reverse proxies inside the ABAP system itself. Principal propagation remains fully supported and is usually the preferred approach whenever an on-premise system's own authorization concept must reflect the real user rather than a shared account; it is not being phased out. What is discouraged is the common shortcut of avoiding the certificate setup effort by hard-coding a broadly authorized communication user for every extension scenario - that pattern shows up repeatedly in audits and runs directly against what clean-core governance expects from extension access.

Basis or security owns Cloud Connector configuration, trust manager entries and certificate lifecycle. The integration or BTP developer owns the API proxy design, policy configuration and the destination setup. A functional or security consultant on the backend side owns the certificate rule mapping to actual authorization roles. Handover must include the certificate expiry schedule and the mapping rule documentation, not just a working configuration snapshot.

Side-by-side extensibility scenarios frequently need principal propagation to call back into an on-premise system as the real user, so that page is a natural companion. Comparing against the older PI/PO-based middleware pattern clarifies exactly what API Management is replacing in terms of proxy and governance capability. Event-driven integration with Event Mesh is a useful contrast because identity propagation does not apply there: events are asynchronous and not tied to a live user session, so the whole principal propagation question falls away.