> For the complete documentation index, see [llms.txt](https://docs.predicthq.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.predicthq.com/api/overview/rate-limits.md). # Rate limits The API rate limits your requests based on the limit specified in your plan. Rate limits are specified in `rps` (requests per second) and the API measures your request rate across a 1-second window. E.g. a rate limit of 50 rps means you can make 50 requests in a second. The rate limit applies to your entire Organization as a whole, regardless of IP address or API Token. If you exceed your rate limit, the API may reject requests with the `429 Too Many Requests` response code until the rate limit resets at the start of the next window. {% hint style="info" %} From time-to-time we may introduce additional temporary rate limits to maintain the reliability of our service. {% endhint %} ### Concurrent requests Your rate limit controls how many requests per second your organization can make, but it does not limit how many of those requests can be in-flight simultaneously. Sending a large number of concurrent requests—even within your rps limit—can cause bursts that exceed your limit, result in `429` errors, and put unnecessary pressure on the API. We recommend limiting the number of concurrent requests your application makes at any one time. A good rule of thumb is to keep concurrent requests well below your rps limit, and to prefer sequential or lightly-concurrent patterns when fetching data in bulk. If you are building a system that needs to make many requests (for example, fetching data across a large number of locations or date ranges), consider: * Using a queue or worker pool with a fixed concurrency limit rather than parallelizing all requests at once * Adding a small delay between requests if you are iterating sequentially * Implementing retry logic with exponential backoff to handle any `429` responses gracefully See Retrying Failed Requests for guidance on backoff and retry behavior. ### Retrying failed requests Ensure you are using appropriate retries and exponential backoff's to work within the rate limits. See the following page with advice on retrying failed requests: * [Troubleshooting](/api/overview/troubleshooting.md#retrying-failed-requests) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.predicthq.com/api/overview/rate-limits.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.