Designing API Proxy Policies: Spike Arrest, Quota, and OAuth Validation

Explanation

Once an API proxy is created in SAP API Management (part of BTP Integration Suite), the real value comes from the policies attached to its request and response flows. Policies are XML-based configuration steps executed by the API Management runtime (Edge Microgateway-based engine in Cloud Foundry environments) at specific points: PreFlow, conditional flows per API path, and PostFlow, each split into request and response phases. Three policy types are central to most production proxies. Spike Arrest protects backend systems from sudden traffic bursts by limiting the rate of requests over a very short time window, expressed as calls per second or per minute. It does not track a rolling quota; it purely smooths bursts to prevent backend overload, which matters when the backend is an on-premise S/4HANA system exposed via cloud connector with limited concurrent connection capacity. Quota, in contrast, enforces a longer-term consumption limit (for example, 1000 calls per day) per API key, app, or developer, and is typically used for commercial or fair-usage enforcement rather than burst protection. Both policies can coexist: Spike Arrest guards the immediate backend, Quota governs business-level consumption per consumer. OAuth validation policies (such as an OAuthV2 VerifyAccessToken step) validate a bearer token issued by an OAuth authorization server before the request reaches the backend. In SAP BTP, this authorization server is commonly the API Management's own OAuth provider or an external identity provider integrated via trust configuration. The verification step checks token validity, expiry, and scope, and can inject verified claims (client_id, scope, custom attributes) into flow variables for use in later policies, such as conditional routing or logging. Design practice is to sequence policies deliberately in the PreFlow request phase: first Spike Arrest (cheapest, protects platform resources immediately), then OAuth/API key verification (rejects unauthorized calls before further processing), then Quota (tracks consumption only for authenticated, legitimate calls). Placing Quota before authentication would let unauthenticated or malicious traffic consume legitimate quota allocations, which is a subtle but serious design flaw. At runtime, when a consumer calls the proxy endpoint, the API Management gateway evaluates the attached policies in order. A Spike Arrest violation returns an HTTP 429-style fault immediately, without invoking the backend. An OAuth failure returns 401/403 with a fault message defined in the policy. Only requests that pass all PreFlow policies are routed to the target backend endpoint, whether that is an on-premise system reached through Cloud Connector, or another BTP/cloud service reached directly. Monitoring and troubleshooting rely on the API Management analytics/reports (available in the Integration Suite cockpit) which show policy-level fault counts, latency breakdown, and traffic patterns per API proxy. When consumers report unexpected 429 or 403 errors, the first triage step is inspecting which policy raised the fault and its configured threshold, not assuming a backend or network issue. Differences across environments: SAP API Management policy syntax and behavior described here applies specifically to the BTP Integration Suite API Management capability; ECC and S/4HANA do not have an equivalent native API gateway layer, and any API exposure from those systems still passes through this same BTP capability or an equivalent gateway product when API-level throttling and OAuth enforcement are required.

Code example

<!-- Simplified PreFlow request policy sequence (conceptual, illustrative only) --><PreFlow name="PreFlow">  <Request>    <Step>      <Name>Spike-Arrest-Protect-Backend</Name>    </Step>    <Step>      <Name>Verify-OAuth-Access-Token</Name>    </Step>    <Step>      <Name>Quota-Per-App-Daily-Limit</Name>    </Step>  </Request></PreFlow> <!-- Spike Arrest policy definition (conceptual) --><SpikeArrest name="Spike-Arrest-Protect-Backend">  <Rate>30ps</Rate></SpikeArrest> <!-- Quota policy definition (conceptual) --><Quota name="Quota-Per-App-Daily-Limit">  <Allow count="1000"/>  <Interval>1</Interval>  <TimeUnit>day</TimeUnit>  <Identifier ref="request.header.apikey"/></Quota> <!-- OAuth verification policy (conceptual) --><OAuthV2 name="Verify-OAuth-Access-Token">  <Operation>VerifyAccessToken</Operation></OAuthV2>

Real project scenario

A retail customer exposed a pricing lookup API backed by an on-premise S/4HANA private cloud system reached through Cloud Connector. During a marketing campaign, a partner's integration retried failed calls aggressively, saturating the Cloud Connector's connection pool and degrading the on-premise system for other consumers. The integration team added a Spike Arrest policy sized to the Cloud Connector's tested capacity, followed by OAuth token verification and a per-partner daily Quota, so that only authenticated partners within their allotted consumption could reach the backend, and burst traffic was smoothed before it ever reached Cloud Connector.

Common mistakes

• Placing the Quota policy before authentication, allowing unauthenticated traffic to consume paid or fair-usage allocations • Setting Spike Arrest thresholds without load-testing the actual backend or Cloud Connector capacity, causing either false throttling or backend overload • Assuming Quota and Spike Arrest serve the same purpose and configuring only one, leaving either burst protection or long-term consumption control missing • Not defining clear fault response messages, leaving API consumers with generic errors that trigger unnecessary support tickets • Forgetting that policy changes require redeploying the API proxy revision, and testing directly in a shared environment without a proper proxy revision/versioning strategy

Best practices

• Always sequence PreFlow policies as Spike Arrest, then authentication/authorization, then Quota • Size Spike Arrest thresholds based on tested backend and Cloud Connector capacity, not arbitrary defaults • Use distinct Quota identifiers (API key, client_id, or custom claim) so business consumption tracking aligns with actual commercial or governance requirements • Define custom fault handling with meaningful HTTP status codes and messages so consumers can distinguish throttling from authentication failures • Use API proxy revisions and a controlled promotion process (dev to test to production) rather than editing policies directly in a production revision • Monitor policy-level fault analytics regularly, not just overall traffic volume, to catch misconfigured thresholds early

Interview angle

Interviewers commonly probe whether a candidate understands the functional difference between Spike Arrest and Quota, and the correct policy ordering rationale (protect first, authenticate second, meter third). Be ready to explain what happens at each policy failure point (HTTP status, backend impact) and how you would design policies differently for a public API portal versus an internal system-to-system integration protecting an on-premise backend.