# Rate Limiting
The API protects itself from excessive load by limiting the rate at which received requests will be processed.
There are several types of rate limit applied, and requests must 'pass' all of these to be successful. I.e. if any one of these different rate limiters is triggered, then the request will be rejected.
**Custom Limits**
The default rate limits are defined below and are subject to change. For now, all subscription plans have the same limits, but this may well change in the future, with the larger plans obviously allowing for higher API usage requirements.
If you are finding your rate limits insufficient, please contact support@testpad.com to discuss what you are trying to do and the possibility of increasing these limits for your account.
---
**Rejected Requests**
Requests rejected for exceeding a rate limit will get a `429 TOO MANY REQUESTS` response.
The response will contain the `Retry-After` HTTP header, specifying how many seconds until a repeat attempt will be successful.
---
**Global (Load Balancer) Rate Limits**
Testpad deploys two types of rate limiter, a global rate limiter that applies to all requests, along with several request-specific limiters that apply different rates for different types of request.
The global rate limit is **1000 requests per hour**, which is an average of **1 request every 3 seconds**, but allows for bursts of up to **100 requests at a time**.
If 100 requests arrived back to back, then the client would have to wait 300 seconds before being able to continue (i.e. maintaining the average rate of 1000 requests per hour).
---
**GET (Fetch) Rate Limits**
For GET (fetch) requests, the API applies two rate limits:
- **1GB** of response data per day, and
- a burst rate limit of **50MB every 3 minutes**
Within any 3 minute period, Testpad will not respond if more
than 50MB of data have already been returned.
And within any 24 hour period, Testpad will not respond if more than 1GB of data has already been returned.
---
**POST (Write) Rate Limits**
For POST (write) requests, the API applies limits to how many scripts
and how many test runs can be created:
- **500 new scripts per month**, and
- a burst limit of **100 scripts per hour**
- **1000 new test runs per month**, and
- a burst limit of **200 test runs per hour**
---
**How the Rate Limits work**
> Note – the following HTTP headers are not implemented yet,
> but we keep their documentation here as they help explain how the rate
> limiters are implemented.
Every API response contains rate limit status information as HTTP headers.
`X-Testpad-Rate-Limit-Read` — Present in responses to GET requests that are attempting to retrieve (read) information.
`X-Testpad-Rate-Limit-Write` — Present in responses to POST requests that are attempting to create information.
The value of these fields is a list of rate limiter names and their current statistics.
Examples:
`fetch_daily[85.2% 893387 of 1048576 KB/day]` — describing the rate limiter called 'fetch_daily' which has a current capacity of 893387 KB (how much more data it will allow through), out of a maximum capacity of 1048576 KB (1 GB) per day.
`scripts_monthly[99.0% 493 of 500 scripts/month]` — describing the rate limited called 'scripts_monthly' which has a current capacity of 493 scripts (how many new scripts it will permit), out of a maximum capacity for 500 new scripts per month.
Rate limiters will reject requests once its current capacity value goes below zero.
The current capacity of each rate limiter is continuously recharging. The value of `Retry-After` is the number of seconds until the capacity level of a rate limiter will go back above zero.
This means that clients do not have to wait e.g. a whole month before they can continue after a 429 error. Instead, they only need to wait until the capacity of the relevant rate limiter has recharged to a positive value again. However, do note that if a request is made immediately after a limiter's capacity has just returned positive, then that capacity is likely to immediately become negative again and thus block subsequent requests.