Protect SAP CPI endpoints with SAP API Management: Spike Arrest, Quota and API governance

1. Introduction

Many organizations expose SAP CPI integration endpoints to connect SAP, legacy systems, external applications or partners. The problem starts when those endpoints are exposed without a consistent layer for governance, traffic control, monitoring and security policies.

2. The problem: CPI endpoints exposed directly

External system
↓
SAP CPI endpoint
↓
iFlow
↓
SAP / non-SAP backend

When CPI becomes the public face, you typically inherit both operational and security risks:

• Traffic bursts (spikes) that degrade availability.
• No consumer identity: difficult to segment or throttle by application.
• Inconsistent controls across iFlows.
• Higher runtime exposure: the iFlow is the direct surface area.
• Limited API-level traceability by product/app.
• DAST/security findings around rate limiting and exposure.
• Performance and availability risk under abuse.

3. Recommended pattern: SAP API Management in front of CPI

External system
↓
SAP API Management
↓ Policies: OAuth / API Key / Spike Arrest / Quota / Access Control
↓
SAP CPI iFlow
↓
Backend

API Management acts as a governed façade. The responsibilities are clean:

• API Management protects, governs, throttles and monitors.
• CPI transforms, routes, orchestrates and executes the integration.

This avoids turning every iFlow into a mini gateway and enables consistent security/governance without touching functional logic.

4. What is an API Proxy?

In SAP API Management, an API Proxy is the API you publish to consumers. The target can be a CPI iFlow endpoint, an SAP service, an external API or a backend system. In this pattern, the target is typically CPI.

Recommended design: the proxy defines contract + policies, while CPI focuses on integration execution.

5. Key policies to protect an API

Policy	Purpose	Example
Spike Arrest	Limit sudden bursts	Protect CPI runtime from “burst traffic”
Quota	Limit total usage per period	Daily/monthly cap per app or product
Verify API Key	Identify consumer apps	Require API keys per registered app
OAuth v2.0 / Verify Access Token	Validate OAuth tokens	Access based on scopes and clients
Verify JWT	Validate JWT tokens	Signature/claims validation before CPI
Access Control	Allow/deny IPs and ranges	Restrict B2B integration to known IPs
XML Threat Protection	Protect against XML attacks	SOAP/XML/iDoc endpoints with safe limits
Message Validation	Validate message structure	Reject out-of-contract payloads early
Assign Message	Modify headers/params/payload	Normalize headers and remove unsafe fields
Service Callout	Call external services	Token endpoints or controlled validation calls

6. Spike Arrest vs Quota

Spike Arrest controls bursts. Quota limits total usage over a period. They are complementary:

• Spike Arrest at 30 requests/min prevents “thousands in seconds”.
• Quota at 3,000 requests/day limits accumulated abuse.

7. Spike Arrest example (XML)

<SpikeArrest async="true" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
    <Rate>30pm</Rate>
    <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

30pm means 30 requests per minute. Avoid relying on client-sent headers for identifiers or message weight unless validated—clients can manipulate them. If you need client-level identification, use a trusted value: a registered application (API key), OAuth client id, or a managed consumer id.

8. How does API Management help with DAST findings?

DAST tools often flag exposed endpoints without controls. API Management helps mitigate findings related to:

• Missing rate limiting.
• Excessive requests.
• No per-consumer controls.
• Endpoints exposed directly.
• Missing monitoring/analytics.
• Insufficient inbound validation.
• Risk of malicious payloads.
• Lack of API governance.

Important: API Management does not replace functional validation inside the iFlow. CPI still needs payload/contract checks, business-rule validations, safe logging and error handling. The mature architecture combines perimeter protection in API Management with functional validation in CPI.

9. Clean Core alignment

This pattern aligns with Clean Core because it:

• Avoids unnecessary direct coupling to CPI.
• Adds a governance layer without touching the core.
• Keeps integrations decoupled and evolvable.
• Improves monitoring and operability.
• Enables homogeneous policies without duplicating security logic in every iFlow.
• Supports an API-first approach with stable contracts.

10. Recommended good practices

• Do not expose CPI endpoints directly for critical external consumers.
• Publish APIs through API Management.
• Use OAuth, JWT or API keys based on required assurance.
• Use Spike Arrest for bursts.
• Use Quota for total usage caps.
• Add Access Control where appropriate.
• Use XML Threat Protection for XML/iDocs/SOAP payloads.
• Keep monitoring and analytics enabled.
• Document consumers, products and policies.
• Separate security/governance from iFlow functional logic.
• Validate payloads inside CPI.

11. Conclusion

SAP API Management does not replace SAP CPI; it complements it. Used together, CPI and API Management let you expose integrations in a safer, governed and scalable way—supporting audits, DAST testing and day-to-day operations with better traceability, control and resilience.

12. If this sounds familiar

At Picasso Tech and Services we help enterprises design, protect and modernize SAP integrations with SAP Integration Suite, SAP CPI and SAP API Management—combining architecture, security and automation to build robust solutions ready for growth.