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
Enable / Disable Rate Limiting
Rate Limiting Toggle
- Disabled (default):
No request limits are enforced. - Enabled:
Requests exceeding the configured limits will be rejected.
Configuration Fields
Window (ms)
Purpose:Defines the time window (in milliseconds) during which requests are counted. Example:
| Window | Milliseconds |
|---|---|
| 1 minute | 60000 |
| 5 minutes | 300000 |
| 15 minutes | 900000 |
| 1 hour | 3600000 |
Max Requests
Purpose:Defines the maximum number of requests allowed within the time window. Example:
Message
Purpose:Custom message returned when the rate limit is exceeded. Example:
Standard Headers
Purpose:Enables modern, standardized rate limit headers. When enabled, responses include headers such as:
Legacy Headers
Purpose:Enables legacy
X-RateLimit-* headers for backward compatibility.
Example headers:
How Rate Limiting Works in DotPortion
When enabled:- Each incoming request is counted per client
- If the limit is not exceeded, the request proceeds
- If the limit is exceeded:
- The request is blocked
- HTTP
429is returned - Custom message is sent
- 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