API rate limits
To ensure the stability, performance, and fair usage of the SE Ranking platform, API rate limits restrict the number of requests an application can make within a given timeframe. Limits are enforced at the API key level, meaning all requests made with the same key—across threads, workers, or servers—are counted together.
SE Ranking evaluates request rates using a rolling one-second window, continuously measuring traffic over the immediately preceding second.
Standard rate limits
Different rate limits apply to the Data API and the Project API:
| API | Use case | Limit (per API key) |
| Data API | Retrieving raw data (e.g., keywords, backlinks, domain analysis, website audit, AI Search). | 10 requests per second (RPS) |
| Project API | Managing account resources (e.g., adding or deleting websites, managing keywords, updating settings). | 5 requests per second (RPS) |
Trial accounts
During the trial period, the Data API has a default rate limit of 1 request per second (RPS). If your evaluation requires higher throughput, this limit can be increased upon request. Please contact our team to discuss your requirements:
Custom rate limits
If your application requires higher throughput than the standard limits allow, custom rate limits are available for both the Data API and the Project API upon request. Please contact our team to discuss your requirements:
Asynchronous operations
For asynchronous endpoints within the Data API (such as /backlinks/export), both the initial request to create the task and any subsequent requests to poll the status endpoint (e.g., /export/status) count against the 10 RPS limit.
Handling rate limits (HTTP 429)
If your application exceeds the defined rate limit (e.g., sending more than 5 requests in one second to the Project API), the API will reject the request and return an HTTP 429 Too Many Requests status code.
{
"error": {
"code": 429,
"message": "Too Many Requests",
"description": "The call-rate limit has been reached. Please reduce your request frequency."
}
}
Best practices for implementation
It is crucial to design your application to handle HTTP 429 errors gracefully. Do not treat a 429 error as a permanent failure, and do not immediately retry the request.
1. Exponential Backoff with Jitter
The industry-standard strategy for handling rate limiting is implementing exponential backoff with jitter.
- Exponential Backoff: Increase the delay between retries exponentially after each failed attempt (e.g., wait 1 second, then 2s, then 4s, then 8s).
- Jitter: Add a small amount of randomization to the delay interval. This is critical to prevent the “thundering herd” problem, where multiple clients become synchronized and attempt to retry simultaneously, immediately causing another rate limit violation.
2. Client-side throttling
We recommend implementing client-side monitoring and request throttling. Proactively managing your request frequency to stay within the defined limits is more efficient than relying solely on error handling.
3. Simple delays (caution)
Because the SE Ranking API uses a rolling one-second window, a brief pause (e.g., 200-500 milliseconds) might be sufficient for occasional, isolated overages. However, exponential backoff provides a significantly more robust solution for high-throughput integrations.
