Skip to main content

​
Rate Limiter

The Rate Limiter helps protect your APIs from abuse, accidental overload, and traffic spikes by limiting how many requests a client can make within a given time window. Rate limiting is configured at the project level and applies to all deployed workflows in the project.

​
What Is Rate Limiting?

Rate limiting enforces a rule like:
“Allow N requests per time window from a client.”
If a client exceeds the limit, DotPortion automatically blocks further requests until the window resets. This helps:
  • Prevent abuse and DDoS-style traffic
  • Protect backend resources
  • Ensure fair usage across clients

​
Configuration UI

📷 Rate Limiter Configuration Form
Rate Limiter Configuration Form

​
Enable / Disable Rate Limiting

​
Rate Limiting Toggle

  • Disabled (default):
    No request limits are enforced.
  • Enabled:
    Requests exceeding the configured limits will be rejected.
💡 Enable rate limiting for all public APIs.

​
Configuration Fields

​
Window (ms)

Purpose:
Defines the time window (in milliseconds) during which requests are counted. Example:
This equals 15 minutes. Common values:

​
Max Requests

Purpose:
Defines the maximum number of requests allowed within the time window. Example:
This allows 100 requests per 15 minutes per client.

​
Message

Purpose:
Custom message returned when the rate limit is exceeded. Example:
This message is returned with an HTTP 429 Too Many Requests response.

​
Standard Headers

Purpose:
Enables modern, standardized rate limit headers. When enabled, responses include headers such as:
✅ Recommended for new applications.

​
Legacy Headers

Purpose:
Enables legacy X-RateLimit-* headers for backward compatibility. Example headers:
⚠️ Use only if required by older clients.

​
How Rate Limiting Works in DotPortion

When enabled:
  1. Each incoming request is counted per client
  2. If the limit is not exceeded, the request proceeds
  3. If the limit is exceeded:
    • The request is blocked
    • HTTP 429 is returned
    • Custom message is sent
  4. Limits reset after the window expires

​
Example Configurations

​
Public API (Moderate Traffic)

​
Internal Dashboard API

​
High-Security Endpoint

​
Best Practices

  • Always enable rate limiting on public APIs
  • Use smaller windows for sensitive endpoints
  • Avoid extremely high limits
  • Use Standard Headers for observability
  • Combine rate limiting with authentication

​
Important Notes

  • Rate limits apply across all workflows in the project
  • Changes require saving the configuration
  • Misconfigured limits may block legitimate users
  • Rate limiting is enforced before workflow execution