Understanding API Rate Limits

Understanding API Rate Limits

Kinexa uses rate limiting to ensure fair usage and protect our infrastructure. Each API plan has different request quotas.

Rate Limits by Plan

Rate Limit Headers

Every API response includes rate limit information in the headers:

• X-RateLimit-Limit — Your maximum requests per window
• X-RateLimit-Remaining — Requests remaining in current window
• X-RateLimit-Reset — Timestamp when the window resets (Unix epoch)

What Happens When You Hit the Limit?

When you exceed the rate limit, you will receive a 429 Too Many Requests response:

{ "error": "Rate limit exceeded. Try again later." }

The response includes a Retry-After header indicating how many seconds to wait.

Best Practices

1. Check headers — Monitor X-RateLimit-Remaining to avoid hitting limits
2. Implement exponential backoff — When you get a 429, wait and retry with increasing delays
3. Cache responses — Reduce unnecessary API calls by caching data locally
4. Use bulk endpoints — Instead of many single requests, use batch/bulk endpoints where available
5. Upgrade your plan — If you consistently need more requests, consider upgrading

Authentication Rate Limits

Login and registration endpoints have stricter limits to prevent brute-force attacks:

• Login: 10 attempts per 5 minutes per IP
• Registration: 5 attempts per 10 minutes per IP
• Password reset: 5 attempts per 10 minutes per IP