PageSightRate Limit Error Handling
Learn how to properly handle rate limit errors and implement retry logic.
Rate Limit Error Response
When you exceed your rate limit, the API returns a 429 Too Many Requests status code.
Loading code...
Error Response Fields
success- Alwaysfalseerror- Error code:rate_limit_exceededmessage- Human-readable error messageretryAfter- Seconds to wait before retrying
Important Headers
Rate Limit Headers
Retry-After- Number of seconds to wait before retrying (present on 429 responses)X-RateLimit-Limit- Your plan's rate limit (e.g., 10, 20)X-RateLimit-Remaining- Requests remaining in current windowX-RateLimit-Reset- Timestamp when the limit resets
Basic Retry Logic
Always respect the Retry-After header when implementing retry logic.
Loading code...
Best Practice
Always use the
Retry-After header value instead of a fixed delay. This ensures you retry at the optimal time.Exponential Backoff
For more robust error handling, implement exponential backoff with jitter.
Loading code...
How Exponential Backoff Works
- • Start with a short delay (e.g., 1 second)
- • Double the delay after each failed retry
- • Cap the maximum delay to avoid excessive waits
- • Still respect the Retry-After header when present
- • Add jitter to prevent thundering herd problems
Error Handling Best Practices
Do
- • Always check for 429 status codes
- • Respect Retry-After headers
- • Implement exponential backoff
- • Log rate limit errors for monitoring
- • Set maximum retry attempts
- • Monitor rate limit headers proactively
Don't
- • Ignore 429 errors
- • Retry immediately without waiting
- • Retry indefinitely
- • Use fixed delays instead of Retry-After
- • Make requests faster than your limit
- • Ignore rate limit headers
Proactive Monitoring
Prevent Rate Limit Errors
Loading code...