API Rate Limiting

Rate limiting protects your serverless runtime from brute-force authentication attempts, denial-of-service (DoS) traffic spikes, and excessive database usage.

API Now! provides a hierarchical rate limiting system where rules can be applied globally, overridden for specific entities, or strictly customized for individual endpoints (actions).

The Rate Limiting Hierarchy

The platform evaluates rate limits starting from the most specific configuration and falling back to more general rules. You can define limits at three distinct levels in the API Modeler:

graph TD
    Action[1. Action Level - Most Specific] -->|If Omitted, Falls Back To| Entity[2. Exposed Entity Level]
    Entity -->|If Omitted, Falls Back To| API[3. API Level - Global Default]

1. API Level (Global Default)

Sets a default fallback rate limit across all endpoints in the API. This ensures that every exposed route is protected by default, even if you do not configure individual limits.

2. Exposed Entity Level

Overrides the global API limit for a specific entity’s collection routes. For example, you might want to configure tighter limits on resource-heavy or sensitive routes (e.g. /invoices or /reports) while keeping the global default for lighter resources.

3. Action Level

Overrides limits at the individual CRUD operation level. For example:

Allow high request rates for listing or reading posts (List or Read actions).
Tightly limit creation or deletion requests (Create or Delete actions) to prevent spam or accidental data loss.

Configuring Rate Limit Rules

Each rate limit configuration is composed of one or more ordered rules. The first rule that matches the incoming request’s context will be applied.

You configure each rule using the following fields in the settings panel:

1. Description (`description`)

A human-readable explanation of what the rule is for (e.g., "Limit anonymous users to 60 requests per hour"). This is strictly for documentation and organization.

2. Grouping Key (`key`)

Determines how requests are grouped together to evaluate the limit. You can select one of three grouping strategies:

IP Address (ip): Groups requests by the client’s IP address. This is the best choice for protecting public-facing, anonymous endpoints.
User ID (userId): Groups requests by the authenticated user’s ID. This is ideal for logged-in users, ensuring a single account cannot overload the system even if they rotate devices or IP addresses.
User Role (role): Applies a shared limit based on a specific user role (e.g., value: "admin" or value: "guest"), allowing you to configure tier-based limits (e.g., higher limits for premium tiers).

3. Allowed Rate (`rate`)

The number of requests allowed during the defined time window. Under the hood, this sets the speed at which tokens are added back to the client’s “request bucket.”

4. Time Interval (`interval`)

The time duration for the rate limits. You can select:

Second
Minute
Hour
Day

5. Burst Capacity (`burst`)

The maximum number of requests a client can make in a quick spike or “burst” before throttling begins. This represents the total capacity of the client’s “request bucket.”

A higher burst capacity allows clients to make rapid, back-to-back requests (e.g., loading a dashboard page that triggers multiple parallel queries) without immediately hitting a rate limit, as long as their overall average stays within the Allowed Rate.

Exceeding Limits

When a client makes too many requests and exceeds the limit, the Serverless Runtime automatically intercepts the call and rejects the request with a 429 Rate Limit Exceeded error response.

For more details on the rate limit response payload, refer to the Rate Limit Exceeded Error Guide.