Skip to main content
When interacting with Geekflare, you might encounter an HTTP 429 Too Many Requests status code. This error indicates that you have sent too many requests in a given amount of time, exceeding the rate limits defined for your plan. This document explains why you’re seeing this error and what steps you can take to resolve and prevent it.

​
Understanding Geekflare Rate Limits

To ensure fair usage and provide consistent performance for all users, Geekflare enforces rate limits on API requests. These limits specify the maximum number of requests you can make requests per second.
Your specific rate limit is determined by your active Geekflare plan — see the per-plan RPS table or API Pricing for full plan details.

​
When a 429 Error Occurs

When a 429 Too Many Requests error occurs, Geekflare will return an HTTP 429 status code. Example API Response:
Key Information in the Response:
  • x-geekflare-ratelimit-second (Header): The maximum number of requests allowed per second for your plan.
  • x-geekflare-ratelimit-remaining-second (Header): The number of requests remaining in the current 1-second window. When this hits 0, you’ll likely receive a 429.
  • x-geekflare-ratelimit-reset (Header): How long until the current rate-limit window resets. Wait at least this long before retrying.
Every response also includes x-geekflare-credits-used and x-geekflare-credits-remaining so you can track your credit balance without a separate dashboard check — see Best Practices.

​
How to Resolve & Prevent 429 Errors

Encountering a 429 error is a signal to adjust your request patterns. Here are the recommended steps:
  1. Wait and Retry (Respect x-geekflare-ratelimit-reset)
    • The simplest and most direct solution. When you receive a 429 error, pause your requests for at least the duration specified in the x-geekflare-ratelimit-reset header. After this period, you can safely retry your original request.
    • Do NOT immediately retry without waiting, as this will only exacerbate the problem and might lead to temporary IP blocking if repeated excessively.
  2. Implement Exponential Backoff with Jitter
    • For more robust applications, especially when dealing with intermittent rate limits or other transient errors, implement an exponential backoff strategy.
    • How it works: If a request fails, wait a short period (e.g., 5 second) before retrying. If it fails again, double the wait time (10 seconds), then (15 seconds), and so on, up to a maximum number of retries or a maximum wait time.
    • Add Jitter: To prevent all your clients from retrying at the exact same moment, add a small random delay (jitter) to your backoff period. For example, instead of waiting exactly 2 seconds, wait between 1.5 and 2.5 seconds.
  3. Monitor Your Usage Proactively
    • In your successful API responses, always look at the x-geekflare-ratelimit-remaining-second header. This tells you how many requests you have left in the current window.
    • By monitoring this header, you can anticipate hitting your limit and adjust your request pace before receiving a 429 error.
  4. Upgrade Your Plan
    • If you consistently hit rate limits and your application genuinely requires higher throughput than your current plan allows, the most effective solution is to upgrade your Geekflare plan.
    • Higher-tier plans come with significantly increased rate limits.
    • Login to Dashboard and Upgrade
  5. Contact Support
    • If you believe you are encountering rate limits in error, or if you have a unique use case that requires custom rate limits beyond our standard plans, please don’t hesitate to contact our support team.
    • Provide as much detail as possible, the approximate time of the errors, and your expected usage patterns.
See the Error Code Reference for other error codes, or Best Practices for retry and concurrency patterns that help avoid rate limits altogether.