Skip to main content

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 in src/utils/api-utils.ts:12-77 with the following parameters:

How It Works

  1. Each IP address gets a 60-request budget per minute
  2. The window starts with your first request
  3. The counter resets after 60 seconds
  4. Requests beyond the limit receive a 429 Too Many Requests response
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

string
Maximum requests allowed per window (60)
string
Number of requests remaining in current window (0 when limited)
string
Unix timestamp (milliseconds) when the rate limit resets
string
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

Response when rate limited:

IP Address Detection

Rate limits are applied per IP address. The system detects your IP from these headers (in order of priority):
  1. x-forwarded-for (first IP in the list)
  2. x-real-ip
  3. cf-connecting-ip (Cloudflare)
  4. Direct connection IP
From src/utils/api-utils.ts:25-29:
If multiple users share the same public IP (e.g., corporate network, shared hosting), they share the same rate limit.

Handling Rate Limits

Best Practices

When you receive a 429 response, wait before retrying:
Reduce API calls by caching responses:
Use POST requests with filters instead of multiple GET requests:
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

Combine multiple strategies:
  1. Cache responses (5-10 minute TTL)
  2. Throttle requests (max 1 per second)
  3. Implement retry logic with exponential backoff
  4. Monitor usage and adjust throttling

Troubleshooting

Possible causes:
  • Multiple users sharing the same IP
  • Previous requests still counting toward limit
  • Aggressive polling or loops
Solution: Implement rate tracking and delay between requests
If your users share a public IP:
  • Consider server-side API calls instead of client-side
  • Implement request queuing on your server
  • Cache aggressively to reduce API calls
Rate limits reset after 60 seconds from the start of the window:
  • Check X-RateLimit-Reset header for exact reset time
  • Ensure you’re waiting for the full Retry-After duration

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