Rate Limiting
Rate Limiting
To protect OpenAlgo from abuse and ensure fair usage, rate limits are enforced at both login and API levels. These limits are configurable via the .env
file and apply globally per IP address.
UI Login Rate Limits
OpenAlgo applies two login-specific rate limits:
Scope | Limit | Description |
---|---|---|
Per Minute | 5 per minute | Allows a maximum of 5 login attempts per minute. |
Per Hour | 25 per hour | Allows a maximum of 25 login attempts per hour. |
These limits help prevent brute-force login attempts and secure user accounts.
API Rate Limits
OpenAlgo implements differentiated rate limiting for various types of operations:
Order Management APIs
Scope | Limit | Description |
---|---|---|
Per Second | 10 per second | Order placement, modification, and cancellation |
Applies to:
/api/v1/placeorder
- Place new orders/api/v1/modifyorder
- Modify existing orders/api/v1/cancelorder
- Cancel orders
Smart Order API
Scope | Limit | Description |
---|---|---|
Per Second | 2 per second | Multi-leg smart order placement operations |
Applies to:
/api/v1/placesmartorder
- Place multi-leg smart orders
Smart orders have the most restrictive limit due to their complexity and additional processing requirements.
General APIs
Scope | Limit | Description |
---|---|---|
Per Second | 50 per second | All other API endpoints including market data |
Applies to all other API endpoints including:
- Market data APIs (quotes, depth, history)
- Account APIs (funds, positions, holdings)
- Information APIs (orderbook, tradebook)
- Search and symbol APIs
Webhook APIs
Scope | Limit | Description |
---|---|---|
Per Minute | 100 per minute | External webhook endpoints from trading platforms |
Applies to:
/strategy/webhook/<webhook_id>
- Strategy webhook from external platforms/chartink/webhook/<webhook_id>
- ChartInk webhook from external platforms
These limits protect against external DoS attacks and webhook flooding.
Strategy Management APIs
Scope | Limit | Description |
---|---|---|
Per Minute | 200 per minute | Strategy creation, modification, and deletion |
Applies to:
/strategy/new
- Create new strategies/strategy/<id>/delete
- Delete strategies/strategy/<id>/configure
- Configure strategy symbols/chartink/new
- Create new ChartInk strategies/chartink/<id>/delete
- Delete ChartInk strategies/chartink/<id>/configure
- Configure ChartInk strategy symbols
These limits prevent strategy management abuse and database flooding.
Configuration via .env
You can adjust the rate limits by editing the following variables in your .env
or .env.sample
file:
# Login rate limits
LOGIN_RATE_LIMIT_MIN="5 per minute"
LOGIN_RATE_LIMIT_HOUR="25 per hour"
# API rate limits
API_RATE_LIMIT="50 per second"
ORDER_RATE_LIMIT="10 per second"
SMART_ORDER_RATE_LIMIT="2 per second"
WEBHOOK_RATE_LIMIT="100 per minute"
STRATEGY_RATE_LIMIT="200 per minute"
These limits follow Flask-Limiter syntax and support formats like:
10 per second
100 per minute
1000 per day
What Happens When Limits Are Exceeded
If a client exceeds any configured rate limit:
- The server will respond with HTTP status
429 Too Many Requests
. - A
Retry-After
header will be sent with the time to wait before retrying. - Further requests will be blocked until the rate window resets.
Security Impact
The rate limiting implementation provides essential protection:
Critical Protection
- External DoS Attacks: Webhook endpoints are protected from unlimited external requests
- System Overload: Strategy operations are protected from flooding
- Resource Exhaustion: Prevents accidental system overwhelming
Attack Vector Mitigation
- Webhook Flooding: External platforms cannot flood webhook endpoints
- Strategy Abuse: Prevents rapid strategy creation/deletion attempts
- Order Flooding: Prevents overwhelming the order management system
Implementation Details
Rate Limiting Strategy
OpenAlgo uses the moving-window strategy for rate limiting, which provides more accurate rate limiting compared to fixed-window approaches.
Storage Backend
Rate limit counters are stored in memory (memory://
), which means:
- Fast performance with minimal latency
- Counters reset when the application restarts
- Suitable for single-user deployments
Key Function
Rate limits are applied per IP address using get_remote_address
as the key function. Each unique IP address has its own rate limit counter.
Version History
- v1.0.1: Single
API_RATE_LIMIT
for all endpoints (10 per second) - v1.0.2: Introduced differentiated rate limits:
- Separate limits for order operations (10 per second)
- Dedicated limit for smart orders (2 per second)
- Increased general API limit to 50 per second
- Added webhook protection (100 per minute)
- Added strategy operation protection (200 per minute)
Recommendations
For API Consumers
- Avoid retrying failed login attempts rapidly
- Spread out API requests using sleep/delay logic or a rate-limiter in your client code
- Use queues or batching when dealing with large volumes of data or orders
- Implement exponential backoff when receiving 429 errors
For Webhook Integration
- Ensure webhook calls are spread out appropriately
- Implement retry logic with delays for webhook failures
- Monitor webhook success rates to detect rate limiting
For Strategy Management
- Avoid rapid creation/deletion of strategies
- Batch symbol configuration operations when possible
- Implement proper error handling for strategy operations
Troubleshooting
Common Issues
- "Rate limit exceeded" errors
- Check your request frequency
- Implement proper retry logic with delays
- Consider using batch operations
- Webhook failures
- Verify webhook rate limits are appropriate for your platform
- Check if external platforms are respecting rate limits
- Monitor webhook logs for patterns
- Strategy operation failures
- Ensure strategy operations are not happening too rapidly
- Check for automated scripts that might be creating excessive requests
- Verify proper error handling in strategy management code
Customization
To modify rate limits:
- Update the values in your
.env
file - Restart the application for changes to take effect
- Ensure the
ENV_CONFIG_VERSION
matches the expected version (1.0.2)
Example customization:
# Increase webhook rate limit for high-frequency platforms
WEBHOOK_RATE_LIMIT="200 per minute"
# Decrease strategy operations for tighter control
STRATEGY_RATE_LIMIT="100 per minute"
# Increase order rate limit for active trading
ORDER_RATE_LIMIT="20 per second"