Why Do We Need Something Like This?

APIs are now everywhere in the digital world! Applications communicate, systems share data, devices are constantly connected to each other. Such open and intense communication inevitably brings some security risks. With misuse, attacks, service interruptions, the question of "who can access?" is no longer enough. We also need to ask "who can access how much?"

In the dynamic world of API development and management, controlling the flow of incoming requests is crucial to maintain system stability, ensure fair usage, and prevent abuse.

This is exactly where we at Apinizer come in:

Our Inspiration: Access Control Lists (ACL)

The concept of "Access Control List" (ACL), which has been used in the security world for many years, serves to determine who can access certain resources. It contains list-based, target-oriented, clear rules. At Apinizer, we thought: "Why not use this logic for rate limiting?"

And the Rate Limit Control List (RLCL) emerged.

ACL vs RLCL: Apinizer's Powerful Dual Solution

Apinizer offers both ACL and RLCL solutions for security and traffic management. Both solutions complement each other to fully protect your APIs:

By using these two powerful mechanisms together, you can make your API security complete. First, determine who can access with ACL, then define the limits of these accesses with RLCL.

What Exactly is RLCL?

As the name suggests: It's a system that allows you to define rate limit rules in a list-based and targeted manner. You are no longer forced to apply a single limit to every IP, every API key, every user. If you wish, you can define special limits such as:

  • 5 requests per second for IP 192.168.1.25
  • 500 requests per minute for API keys starting with client-abc-*
  • 10,000 requests per day for specific user IDs

You can also make regex-supported or conditional definitions (for example, different during working hours and different outside working hours). So the era of "one rule for everyone" is over!

How Does RLCL Work in Apinizer?

It's not complicated, the steps are clear:

  1. A request arrives.
  2. Identity information is obtained from the request (IP, header, user ID, etc.).
  3. It checks if this information is defined in RLCL (does it match with the list or regex?).
  4. If it matches, the specially defined rate limit rule for it is activated.
  5. If it doesn't match, either the general limit works or no limit is applied (according to policy).
  6. If the limit is exceeded, the request is rejected (usually with a 429 Too Many Requests error).
  7. Optionally, the rate limit status can be added to response headers (X-RateLimit-*).

Flexibility of Apinizer RLCL

Apinizer's Rate Limit Control List solution stands out with its flexibility:

Time Window Options

RLCL supports both Fixed Window (FIXED) and Sliding Window (SLIDING) approaches:

  • Fixed Window: Counters are reset in specific time periods (e.g., at the beginning of each hour)
  • Sliding Window: Requests within the last X minutes/hours/days are evaluated for any given moment

This allows you to provide solutions suitable for different business scenarios.

Dynamic Identity Definition

Apinizer RLCL offers extremely flexible options for determining the identity of the request:

  • IP address
  • API key
  • User ID
  • Request headers
  • Cookie values
  • URL parameters
  • Fields in the request body

You can even use combinations of these! For example, you can define special rules for "requests coming from a specific IP block with a specific user ID."

Regex Support

RLCL allows you to create extremely powerful matching rules using Regular Expressions. For example:

  • All IP addresses starting with ^192.168.
  • All API keys in the format api-key-[0-9]+
  • Email addresses with a specific domain extension

This way, you can reduce your management burden by defining patterns rather than individual values.

Settings are Simple and Understandable

As Apinizer, we maintain our principle of ease of use and provide you with simple and understandable interfaces. We handle the difficult part in the background for you. Without having to worry about complex rate limiting mechanisms and algorithms, you can meet all your needs with the following simple settings:

  • Name and Description: For ease of management.
  • Working Order: Will it work before or after other policies?
  • Time Window Type: Fixed or sliding?
  • Allowed Request Count: How many requests can pass?
  • Time Interval: You can specify as seconds, minutes, hours, days, months.
  • Identity Variable: Is it IP, API key, or user ID?
  • Target Identities: You can define as a list or with regex.
  • Response Headers: Do you want to show rate limit statistics?

Why RLCL? What's the Difference?

  • Granular control: You give clear answers to the question of who can access how much.
  • Targeted limitation: A single bad actor cannot lock your entire API.
  • Flexibility: Partner, customer, service — whoever they are, you can define different SLAs.
  • Transparency: You can also include remaining limit information in responses.
  • Manageability: Definitions are plain and readable.
  • Performance: Works fast with cache support, doesn't slow down your system.

Real-Life Examples

  • Free vs. Premium Users: In your freemium model service, you can apply a limit of "100 requests per day" to free users and "50 requests per second" to premium users. Your API is both accessible and fair.
  • Geographical-Based Protection: You can apply different limits to requests coming from certain countries or IP blocks. This is especially useful for suspicious traffic sources.
  • DDoS Prevention: You can instantly detect IPs sending suddenly high traffic and bring special restrictions. This way, you isolate the problem without affecting your other users.
  • Partner Management: You can define special API usage limits for each of your business partners. According to everyone's needs — while some make 1000 requests per minute, others can make 10 requests per hour.

Final Word

As Apinizer, we wanted to bring a new breath to API security and management. We transformed rate limits from just a number into a targeted, flexible, and powerful control tool. Because we know that in the modern API world, "the same rules for everyone" is no longer enough.

Our Rate Limit Control List solution stands out with its adaptable structure for different needs, easy configuration, and powerful performance. You can check our Apinizer documentation for detailed technical information.

With Apinizer, you now determine who accesses how much.