The Seelab API is subject to global rate limits, which apply to all subscription plans equally. These global limits are set at 100 requests within a 10 seconds window, using a sliding window algorithm to manage the rate of incoming requests.
The sliding window algorithm continuously monitors the number of requests made within the defined time window, allowing a certain number of requests per second. As each new request is made, the window "slides" forward, ensuring that the rate limit is enforced dynamically based on recent activity.
These rate limits are subject to change, so it is important for API clients to implement automated retry logic to handle rate limiting appropriately. This ensures that your application can gracefully handle temporary rate limit errors and continue to operate smoothly.
Response Headers and Body for Rate Limits
When rate limits are applied, specific headers are included in the response to help you understand the current rate limit status. Below is an explanation of the response headers you might encounter:
| Name | Description | Example |
|---|---|---|
| X-RateLimit-Limit | The maximum number of allowed requests in the time window of 10 seconds. | 5 |
| X-RateLimit-Remaining | The number of remaining requests that the client can make in the current time window before reaching the rate limit. | 3 |
| X-RateLimit-Retry-After | Indicates how long (in seconds) the client needs to wait before they are allowed to make more requests after the rate limit has been exceeded. | 0 |
If the rate limit is exceeded, the API will respond with an HTTP 429 status code. Below is an example of the response body in such a scenario:
{
"error": 1000,
"message": "Rate limit exceeded",
"data": {
"type": "rateLimit",
"limit": 5,
"retryAfter": 3
}
}
Example of response headers when rate limits have not been reached:
X-RateLimit-Limit: 5
X-RateLimit-Remaining: 3
X-RateLimit-Retry-After: 0