Apinizer Rate Limit Mechanisms Comparison
For rate limiting to work effectively on Apinizer, quota and throttling are handled separately:
- Short-term request limits (seconds/minutes) are expressed as throttling.
- Long-term request limits (days/months/years) are expressed as quota.
For a general explanation of these concepts, see Rate Limit, Throttling and Quota Management.
Rejecting incoming load in a controlled way is better than letting the service become unavailable under heavy load.
On Apinizer, rate limits can be defined, applied, and managed through three different mechanisms:
General or endpoint-specific restriction on the API Proxy
Independent limits specific to each client identity
Targeted, granular rules at endpoint level
What Is Policy-Based Rate Limit?
Policy-based rate limit is a general or endpoint-specific restriction defined on an API Proxy. Unless a specific condition is set, it applies to all requests reaching that proxy without distinguishing users.
Policy-based rate limit typically includes:
- A single request limit defined at proxy level
- Equal application to all traffic unless a specific target audience is separated
- Simple time window definitions (per second/minute/hour)
- Separation by IP, API key, header, etc. through the Apply By option
- Custom rules for specific endpoints or conditions through Condition
What Is Credential-Based Rate Limit?
Credential-based rate limit restricts requests according to the limit value defined specifically for the credential (API key, token, client ID, etc.) that sends requests to the API. Each credential is evaluated independently against its own rate limit value. The purpose of credential-based rate limiting is to control and limit the traffic load created by API stakeholders.
Credential-based rate limit especially includes:
- Independent request limits defined per credential
- Ability to assign different limit values to different customers or applications
- Traceability of credential-based usage metrics
- Natural alignment with subscription/plan models
What Is Rate Limit Control List (RLCL)?
Rate Limit Control List (RLCL) is a technical mechanism developed by Apinizer that lets you define rate limit rules based on a wide variety of parameters such as IP address, HTTP headers, request body content, and environment variables. Unlike policy- and credential-based approaches, RLCL works only at endpoint level; each endpoint must be configured separately.
A defined RLCL can be applied to multiple API Proxies at once.
RLCL especially includes:
- Targeted limit definitions based on IP, header, body, and environment variables
- Endpoint-based application (valid only on the relevant endpoint, not proxy- or credential-wide)
- Flexible target audience conditions with operators (equals, contains, starts with, etc.)
- Time window types (fixed or sliding)
- Action definitions for requests outside the target audience (block or apply general quota)
Key Differences Between the Three Mechanisms
| Policy-Based | Credential-Based | RLCL | |
|---|---|---|---|
| Application level | API Proxy / method (policy position) | Credential × API Proxy (ACL) | API + endpoint |
| Separation criteria | Optional (Apply By, condition, Detail List) | Credential identity | IP, header, body, credential, auth user, etc. |
| Configuration location | Development → Policies | Identity Management → ACL | Identity Management → RLCL |
| Time window | Throttling (sec/min) + Quota (hour/day/month) | Throttling + Quota | Flexible (sec → month) |
| Flexibility | Medium (simple → advanced) | Medium | High |
When to Use Which?
Use policy-based rate limit when
- You want to limit all traffic to a proxy with a single rule
- You do not need separation by credential or request content
- You want to build a quick, low-cost general protection layer
- You want to create the first line of defense for the system
Use credential-based rate limit when
- You want to define different usage rights for different customers or applications
- You want to reflect your subscription/plan structure (free, pro, enterprise, etc.) technically
- You need credential-based usage tracking and reporting
- Each client must be limited according to its own API consumption
Use RLCL when
- You want to define customized limits for a specific endpoint based on IP, header, or body content
- You want to limit a specific operation type (e.g. batch operations) differently from others
- You want to target suspicious IP blocks or specific behavior patterns
- The most precise and granular technical control is required
How to Use All Three Together
Policy-based rate limit, credential-based rate limit, and RLCL are not competitors; they are complementary layers. Below are the benefits and examples of using all three together:
Layered protection: With policy-based rate limit you set an upper bound across the proxy, with credential-based rate limit you control each customer's usage rights, and with RLCL you manage special cases on specific endpoints.
Flexible business model:
- Policy: No more than 10,000 requests per second are accepted on the proxy in total
- Credential: Each credential is limited between 50 and 500 requests per second according to its plan
- RLCL: Requests to the
/api/v1/batchendpoint cannot exceed 5 requests per second regardless of source IP or body content
Security and operational stability:
- Policy-based rate limit forms the first line of defense against general overflow scenarios
- Credential-based rate limit applies the business model and customer segmentation at the technical level
- RLCL provides targeted protection against special risk or load scenarios on specific endpoints
Flexibility for special cases:
- Policy and credential: Under normal conditions, each credential operates according to its plan limit
- RLCL: Requests to a specific endpoint, with a specific header value, or from a specific IP range are additionally limited independently of the credential limit
Example Scenario: Payment API Served Through an API Gateway
Consider a payment service API:
Across the API Proxy: at most 5,000 requests per second (general overflow protection)
Standard customer credentials: at most 200 requests per minute. Enterprise customer credentials: at most 2,000 requests per minute
For /api/v1/payments/refund: at most 3 requests per second from the same IP. For high-amount body requests: at most 1 request per minute. Exemption from endpoint-based limits for requests with the X-Client-Type: internal header
In this configuration, policy-based rate limit protects the system against general overflow, credential-based rate limit reflects the business model and customer segmentation, and RLCL ensures that high-risk operations (such as refunds or high-amount payment requests) are additionally and more strictly controlled at endpoint level.
Conclusion
Policy-based rate limit, credential-based rate limit, and Rate Limit Control List (RLCL) are different but complementary ways to control API traffic. Policy-based rate limit forms the general protection layer of the system, credential-based rate limit applies the business model and customer segmentation at the technical level, and RLCL provides the most precise and flexible control at endpoint level. In an ideal rate limiting strategy, all three approaches should be used together, complementing each other with their own strengths.
The three mechanisms offered by Apinizer let you build a layered protection model instead of relying on a single rule. This way you can set an upper bound across the system, define usage rights appropriate to each customer's plan, and take targeted measures against special risk scenarios on specific endpoints.