Overview
To ensure fair usage and maintain service quality, the Dzaleka Online Services API implements rate limiting based on IP address.Current rate limit: 60 requests per minute per IP address
Rate Limit Configuration
The rate limiting system is implemented insrc/utils/api-utils.ts:12-77 with the following parameters:
How It Works
- Each IP address gets a 60-request budget per minute
- The window starts with your first request
- The counter resets after 60 seconds
- Requests beyond the limit receive a
429 Too Many Requestsresponse
Rate limits are tracked in-memory and reset automatically. The system periodically cleans up expired entries.
Rate Limit Headers
When you exceed the rate limit, the API returns these headers:Header Descriptions
Maximum requests allowed per window (60)
Number of requests remaining in current window (0 when limited)
Unix timestamp (milliseconds) when the rate limit resets
Number of seconds to wait before making another request
Rate Limit Response
When you exceed the rate limit, you’ll receive this response:Example Rate Limit Error
IP Address Detection
Rate limits are applied per IP address. The system detects your IP from these headers (in order of priority):x-forwarded-for(first IP in the list)x-real-ipcf-connecting-ip(Cloudflare)- Direct connection IP
src/utils/api-utils.ts:25-29:
Handling Rate Limits
Best Practices
Implement Exponential Backoff
Implement Exponential Backoff
When you receive a 429 response, wait before retrying:
Cache API Responses
Cache API Responses
Reduce API calls by caching responses:
Batch Requests
Batch Requests
Use POST requests with filters instead of multiple GET requests:
Monitor Usage
Monitor Usage
Track your API usage to avoid hitting limits:
Code Examples
JavaScript with Rate Limit Handling
Python with Rate Limit Handling
cURL with Manual Retry
Rate Limit Strategies
Strategy Comparison
| Strategy | Pros | Cons | Best For |
|---|---|---|---|
| Request Queue | Prevents rate limit errors | Slower overall | Background jobs |
| Exponential Backoff | Automatic recovery | Adds complexity | Production apps |
| Client-side Caching | Reduces API calls | Stale data possible | Read-heavy apps |
| Request Throttling | Smooth traffic | May not use full quota | High-volume apps |
Recommended Approach
Combine multiple strategies:- Cache responses (5-10 minute TTL)
- Throttle requests (max 1 per second)
- Implement retry logic with exponential backoff
- Monitor usage and adjust throttling
Troubleshooting
Getting 429 Errors Immediately
Getting 429 Errors Immediately
Possible causes:
- Multiple users sharing the same IP
- Previous requests still counting toward limit
- Aggressive polling or loops
Rate Limit Not Resetting
Rate Limit Not Resetting
Rate limits reset after 60 seconds from the start of the window:
- Check
X-RateLimit-Resetheader for exact reset time - Ensure you’re waiting for the full
Retry-Afterduration
Future Enhancements
The following features are under consideration for future releases:
- Higher rate limits for authenticated users
- Per-user rate limiting (instead of IP-based)
- Rate limit headers on all responses (not just 429s)
- Burst allowance for occasional spikes
Next Steps
API Overview
Learn about available endpoints and response formats
Authentication
Understand CORS configuration and headers