What Are the API Rate Limits?

The Generator Labs API enforces two levels of rate limiting to ensure fair usage and system stability.

Hourly Limit

Each API application is limited to 1,000 requests per hour. This is an overall cap across all endpoints.

Per-Second Limits

Individual endpoints have per-second rate limits based on the type of operation:

Operation Type	Endpoints	Limit
Read	GET /rbl/hosts, GET /rbl/listings, GET /cert/monitors, etc.	100 requests/second
Write	POST /rbl/hosts, PUT /rbl/hosts/{id}, DELETE /rbl/hosts/{id}, etc.	50 requests/second
Manual Check	GET /rbl/check/start	10 requests/second

Rate Limit Headers

Every API response includes rate limit information using the following headers:

RateLimit-Limit: 1000;w=3600, 100;w=1
RateLimit-Remaining: 95
RateLimit-Reset: 1

• RateLimit-Limit lists all active policies. The w= parameter indicates the window size in seconds. For example, 1000;w=3600 means 1,000 requests per hour, and 100;w=1 means 100 requests per second.
• RateLimit-Remaining shows the number of requests remaining in whichever policy is most restrictive at that moment.
• RateLimit-Reset indicates the number of seconds until the most restrictive window resets.

The per-second value in RateLimit-Limit changes depending on the endpoint you are accessing.

When You Are Rate Limited

If either limit is exceeded, the API returns a 429 Too Many Requests response with a Retry-After header:

HTTP/1.1 429 Too Many Requests
Retry-After: 1
RateLimit-Limit: 1000;w=3600, 10;w=1
RateLimit-Remaining: 0
RateLimit-Reset: 1

The Retry-After value tells you how many seconds to wait before retrying. For per-second limits this is 1, for the hourly limit it will be the number of seconds remaining in the current hour.

Transient Service Conditions

A 429 does not always mean you exceeded a rate limit. The API also returns 429 (with the same Retry-After and RateLimit-* headers) when it cannot serve a request because of a temporary infrastructure condition, such as the database being briefly unavailable. This lets you reuse the same back-off logic for both cases: when you receive a 429, wait for the Retry-After duration and retry, rather than treating it as a hard failure.

Best Practices

• Check the RateLimit-Remaining header to avoid hitting limits.
• If you receive a 429 response, wait for the duration indicated in Retry-After before retrying.
• Remember that your monitoring data only changes as checks are processed. If your check frequency is once per day, polling the API every few minutes provides no additional value.