Enforcing Rate Limits Using Dynamic Keys from Request Headers

In this blog, we will learn how to enforce rate limits using dynamic keys from Request Headers.

Rate limiting is a key mechanism for controlling the volume of requests made to an API within a defined time window. It helps safeguard APIs from excessive traffic, ensures equitable usage among consumers, and prevents service degradation due to overload.

In IBM API Connect, rate limits can be configured at both the API and Plan levels to regulate traffic and usage patterns. The platform provides a Rate Limit policy that allows you to enforce one or more rate, burst, or count limits at any point within the API assembly flow.

Dynamic Rate Limiting Based on Request Attributes

While standard rate limits are typically applied uniformly across consumers, there are scenarios where limits must be enforced based on dynamic request attributes—such as a username, IP address, or server name. These attributes may not be predefined in the rate-limit schema.

To support this, API Connect allows the use of dynamic value strings that reference context variables. These variables can be set using a GatewayScript or a Set Variable policy, and then injected into the rate-limit configuration.

Example Scenario

Consider an API consumer subscribed to an application that is accessed by multiple partners. To ensure fair usage, you need to apply rate limits individually per partner, based on the partnerId received in the request header.

To implement this:

• Define a rate-limit policy in the API assembly.
• Use a dynamic value string that points to the partnerId
• Ensure the corresponding Plan in the Product defines the rate-limit name referenced in the assembly.

Syntax Reminder: Dynamic value strings must follow the format $(context variable).

Example:

value: “$(ratelimit.key)” where ratelimit.key is set to message.headers.partnerId.

Expected Outcome 

Behavior at Runtime

• Each incoming request is evaluated for its partnerId
• The API Gateway sets a context variable (e.g., key) to that partnerId.
• The rate-limit policy uses this dynamic value to enforce limits per unique partner.

Result

• Partner-specific throttling: Each partner gets their own rate-limit bucket.
• If partnerId=ABC123 exceeds the quota, only that partner receives a 429 Too Many Requests.
• Other partners (e.g., partnerId=XYZ789) continue to access the API within their own limits.

Benefits

• Prevents one partner from consuming all available quota.
• Supports multi-tenant fairness without duplicating APIs or plans.
• Enables scalable, context-aware traffic control.

 Example

Request Header	Rate Limit Applied	Outcome
partnerId: ABC123	100 requests/hour	Allowed until quota
partnerId: XYZ789	100 requests/hour	Independent quota
partnerId: ABC123 (after 100 calls)	Quota exceeded	429 Too Many Requests

Implementation

We can leverage the below limits to apply Throttling dynamically.

• assembly-rate-limit
• assembly-burst-limit
• assembly-count-limit

Step 1: Create an API and Use the Assembly Rate Limit Action

Step 2: Configure RateLimit Policy with ‘Plan By Name’ Option

Step 3: Create a Product and Go to Source

Note: You can’t dynamically change rate limits in a published plan at runtime using GatewayScript or API assembly logic — but you can update them programmatically before deployment using the IBM API Connect REST APIs or CLI.

Testing

Conclusion

Through this R&D exercise, we successfully implemented dynamic rate limiting in IBM API Connect by leveraging context-aware throttling mechanisms. Specifically, we utilized a combination of clientId and appId extracted from incoming request headers to construct a dynamic value string that uniquely identifies each consumer context.

By setting this composite key (We can leverage it within in GatewayScript and reference it as well) within the rate-limit policy, we achieved precise control over API usage per client-application pair. This approach ensures that rate limits are enforced individually for each clientId-appId combination, enabling scalable multi-tenant traffic management without duplicating plans or APIs.

This solution validates the capability of IBM API Connect and DataPower Gateway to support advanced throttling scenarios using dynamic keys, and lays the foundation for future enhancements such as time-windowed quotas and adaptive usage tiers.