Rate Limits

Sorsa enforces a single, universal rate limit to keep the service fast and stable for everyone. No per-endpoint tiers, no rolling windows, just one number to design around.

The rule: 20 requests per second

Every API key is limited to 20 requests per second. That is the only rate limit. There are no per-endpoint limits, no 15-minute windows, no hourly resets, and no differences between plans. Stay under 20 req/s and you will never see a rate limit error. A few details worth knowing:

The limit applies per API key, not per IP address. If you have multiple keys, each gets its own 20 req/s allowance.
Every request counts equally. A single /info call and a /tweet-info-bulk call carrying 100 tweets both count as one request.
It is not a sliding window. The count resets every second. If you send 20 requests at T+0.00, you can send another 20 at T+1.00.

What happens when you exceed the limit

If you send more than 20 requests in one second, the API returns 429 Too Many Requests for the excess. No data is lost and your key is not penalized. Wait until the next second and retry. There are no x-ratelimit-remaining or x-ratelimit-reset headers. Because the limit resets every second, tracking remaining credits in headers would add complexity without much practical value.

How to stay within the limit

For most workloads you will never approach 20 req/s during normal operation. If you are running batch jobs or processing large datasets, here are two simple approaches.

Option 1: Fixed delay between requests

The safest approach is a 50ms pause (one twentieth of a second) between consecutive requests. This caps your throughput at 20 req/s, exactly the maximum allowed. Python

import time
import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.sorsa.io/v3"

usernames = ["elonmusk", "naval", "paulg", "vaborsh"]

for username in usernames:
    response = requests.get(
        f"{BASE_URL}/info",
        params={"username": username},
        headers={"ApiKey": API_KEY},
    )
    print(response.json()["display_name"])
    time.sleep(0.05)  # 50ms between requests

JavaScript

const API_KEY = "YOUR_API_KEY";
const BASE_URL = "https://api.sorsa.io/v3";

const usernames = ["elonmusk", "naval", "paulg", "vaborsh"];

for (const username of usernames) {
  const res = await fetch(`${BASE_URL}/info?username=${username}`, {
    headers: { ApiKey: API_KEY },
  });
  const data = await res.json();
  console.log(data.display_name);
  await new Promise((r) => setTimeout(r, 50)); // 50ms between requests
}

Option 2: Retry on 429

If you prefer to run at full speed and handle limits reactively, catch 429 responses and retry after a short pause. Python

import time
import requests

def fetch_with_retry(url, headers, max_retries=3):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)

        if response.status_code == 429:
            time.sleep(1)
            continue

        return response.json()

    raise Exception("Rate limit: max retries exceeded")

JavaScript

async function fetchWithRetry(url, headers, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const res = await fetch(url, { headers });

    if (res.status === 429) {
      await new Promise((r) => setTimeout(r, 1000));
      continue;
    }

    return await res.json();
  }
  throw new Error("Rate limit: max retries exceeded");
}

In practice, combining both works best: a small delay to avoid 429s in the first place, plus retry logic as a safety net.

Batch endpoints reduce the need for high throughput

Before optimizing for speed, check whether batch endpoints can cut your total request count:

/info-batch fetches up to 100 user profiles in a single request
/tweet-info-bulk fetches up to 100 tweets in a single request

One batch request counts the same as one regular request against both your rate limit and your quota. When you need data for many users or tweets, batching is almost always more efficient than firing individual requests in parallel. For more patterns like this, see the Optimizing API Usage guide.

Need a higher limit?

If your project needs sustained throughput above 20 req/s (for example, 100+ req/s for a real-time monitoring pipeline), reach out through Talk to Sales or our Discord to discuss dedicated infrastructure and custom plans.

Next steps

Pagination - Fetch large datasets efficiently within the rate limit
Error Codes - Full reference for 400, 401, 403, 404, 429, and 500 responses

Getting started

Core Mechanics

Solution Guides

Support & Resources

The rule: 20 requests per second

What happens when you exceed the limit

How to stay within the limit

Option 1: Fixed delay between requests

Option 2: Retry on 429

Batch endpoints reduce the need for high throughput

Need a higher limit?

Next steps

​The rule: 20 requests per second

​What happens when you exceed the limit

​How to stay within the limit

​Option 1: Fixed delay between requests

​Option 2: Retry on 429

​Batch endpoints reduce the need for high throughput

​Need a higher limit?

​Next steps

The rule: 20 requests per second

What happens when you exceed the limit

How to stay within the limit

Option 1: Fixed delay between requests

Option 2: Retry on 429

Batch endpoints reduce the need for high throughput

Need a higher limit?

Next steps