# 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**
Each rate limiter has a capacity that it spends as it lets requests through, and that recharges continuously over time. A limiter rejects requests once its capacity drops below zero.
The `Retry-After` header on a `429` response tells you how many seconds until the relevant limiter has recharged back above zero. So you don't have to wait a whole month after hitting a monthly limit: you only wait until enough capacity has recharged.
One thing to watch: a request made the instant a limiter turns positive is likely to drive it straight back negative and block what follows. If you're near a limit, back off a little beyond `Retry-After`.