API Rate Limits

Last updated: October 10, 2025

Overview

To ensure the stability, performance, and fair usage of the SE Ranking platform for all users, the API enforces rate limits. Rate limits restrict the number of requests an application can make to the API within a specific timeframe.

These limits are applied at the API key level. This means the cumulative traffic from all sources (threads, workers, or servers) using the same key must adhere to the thresholds.

SE Ranking uses a rolling one-second window for evaluation. The API continuously monitors the request rate over the immediately preceding second.

Trial Accounts

During the trial period, the Data API has a default rate limit of 1 request per second (RPS). If your evaluation requires a higher throughput, we are happy to increase this limit for you. Please connect with our team to discuss your needs:

• Book a meeting
• Email us: [email protected]

Standard Rate Limits

The enforced limits depend on which API you are accessing.

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 (Error 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.

429 Response

The response body will indicate that the call-rate limit has been reached.

{

  "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.

Custom Rate Limits

If your application requires higher throughput than the standard limits allow, we offer custom plans tailored to high-volume needs for both the Data API and the Project API.

To discuss increasing your rate limits, please get in touch with our team:

• Book a meeting
• Email us at [email protected]