Twitter API benchmark: latency, errors and uptime

#What a Twitter API benchmark measures

A Twitter API benchmark measures how long a read takes, how often it returns the data you asked for, and how much data one read brings back, under the same conditions for every API it compares. Response time is the time from sending a request to receiving the last byte of the answer. One number never covers all of it, so a useful benchmark reports five.

• Median response time

  What it tells you

  The wait a typical request sees

  How a fair test reports it

  Per task, from a named place

• 90th percentile and maximum

  What it tells you

  The slow requests that stall a long job

  How a fair test reports it

  Next to the sample size

• Success share

  What it tells you

  How many requests returned valid data

  How a fair test reports it

  A 200 with an empty or wrong body counts as a failure

• Items per request

  What it tells you

  How much one call returns

  How a fair test reports it

  1, 20, 100 or 200, from the docs

• Requests per second

  What it tells you

  How fast you may send calls

  How a fair test reports it

  The plan's limit per key, not a short burst

The first three describe a single request. The last two decide how long a whole job takes, and that is usually the number you are buying.

Every request also splits into parts that different people control. Looking up the server's address (DNS), opening the connection (TCP) and agreeing on encryption (TLS) depend mostly on the distance between you and the API, and you pay them once per connection. The server's wait, from the request to the first byte of the answer, is the API's own work. The download depends on the size of the answer and your bandwidth.

A test that opens a fresh connection for every call measures the distance to the API as much as the API. A test that reuses the connection measures what a real client sees after its first request. Both are valid; a benchmark should say which one it ran.

Delivery latency is a different measure: the time from a post going live to the moment a push feed hands it to your app. It belongs to push feeds and to real-time Twitter monitoring, not to the response time of a read.

#Why the official X API can't be in a Twitter API benchmark

The official X API can't appear in a fair benchmark because X's Developer Policy (opens in a new tab) forbids using it to measure X's performance for benchmarking or competitive purposes. Its own example of what not to do is to "measure or analyze the responsiveness of X".

That is why "official X API latency" rows in AI answers and comparison tables come from something else. One common source is a monitor that probes the api.twitter.com host from cloud regions: it times the host's answer, with no price, quota or post count behind it. Another is X's note that its streaming endpoints have a "P99 latency of approximately 4-5 seconds", which X documents for streams (opens in a new tab), not for reads.

What a buyer can compare is published: the price, the ceiling and the access rules. On those, the official X API charges $5.00 per 1,000 posts against Sorsa API's from $0.014, and stops pay-per-use at 3 million post reads a month.

• Price per 1,000 posts

  Sorsa API

  from $0.014

  Official X API

  $5.00

• Price per 1,000 followers

  Sorsa API

  from $0.007

  Official X API

  $10.00

• Monthly ceiling

  Sorsa API

  Set by your plan

  Official X API

  3M post reads, then Enterprise from about $42K a month

• Rate limit

  Sorsa API

  20 requests per second per key, every plan

  Official X API

  Per endpoint, in 15-minute windows

• Access

  Sorsa API

  One API key

  Official X API

  Developer account and OAuth

X's prices and the 3M cap are on its pricing page (opens in a new tab); the windows are in its rate limits reference (opens in a new tab), and our guide to X API rate limits walks through them endpoint by endpoint.

#How long a Twitter data job takes

A job takes as many requests as it needs items divided by items per request, sent at the rate limit you have, so batch size and requests per second decide job time more than any single response time does. A million tweets by ID take 10K requests in batches of 100: about 8 minutes at 20 requests per second. One ID per request turns the same job into a million requests, about 14 hours at the same rate.

To read tweets in bulk, use Sorsa API, a Twitter (X) API and scraper: POST /tweet-info-bulk (opens in a new tab) returns up to 100 tweets with their authors' full profiles per request, at 20 requests per second on every plan, free accounts included. That is up to 2,000 tweets a second on one key, from $0.014 per 1,000 against $5.00 on the official X API.

Batch lookups run in parallel, because every batch of IDs stands on its own. Profiles work the same way: GET /info-batch (opens in a new tab) takes up to 100 usernames or IDs per request. Follower lists and searches follow a cursor: GET /followers (opens in a new tab) returns up to 200 followers per page and POST /search-tweets (opens in a new tab) about 20 tweets, and each page needs the cursor from the one before. Those jobs reach full speed when several accounts or queries run side by side.

To run a batch job at the full rate:

1. Get a key. Sign up and copy the API key from the dashboard. The first 100 requests are free.

2. Send one batch. Post up to 100 tweet IDs or links in tweet_links, with the key in the ApiKey header.

   curl -X POST "https://api.sorsa.io/v3/tweet-info-bulk" \
     -H "ApiKey: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"tweet_links": ["1985104432771637431", "1985099018413273260"]}'
   

   {
     "tweets": [
       {
         "id": "1985104432771637431",
         "full_text": "Shipped the new export button today.",
         "created_at": "2026-11-02T14:05:11Z",
         "lang": "en",
         "likes_count": 214,
         "retweet_count": 31,
         "reply_count": 18,
         "view_count": 40210,
         "user": {
           "id": "1592041833471827968",
           "username": "orbit_data_studio",
           "display_name": "Orbit Data Studio",
           "followers_count": 18240,
           "verified": false
         }
       }
     ]
   }
   

   Show full response

3. Run batches side by side. Start up to 20 requests a second, wait and retry on 429 and 500, and stop on any other error, since it repeats until you fix the request or the key.

   import time
   from concurrent.futures import ThreadPoolExecutor
   
   import requests
   
   URL = "https://api.sorsa.io/v3/tweet-info-bulk"
   HEADERS = {"ApiKey": "YOUR_API_KEY"}
   RATE = 20  # requests per second per key, every plan
   
   
   def fetch(batch, tries=5):
       for attempt in range(tries):
           r = requests.post(URL, headers=HEADERS,
                             json={"tweet_links": batch}, timeout=30)
           if r.status_code == 200:
               return r.json()["tweets"]
           if r.status_code in (429, 500):
               time.sleep(2 ** attempt)  # 1, 2, 4, 8, 16 seconds
               continue
           r.raise_for_status()  # 400, 401, 403, 404: fix it, don't retry
       raise RuntimeError("batch still failing after retries")
   
   
   def hydrate(ids):
       batches = [ids[i:i + 100] for i in range(0, len(ids), 100)]
       with ThreadPoolExecutor(max_workers=RATE) as pool:
           jobs = []
           for batch in batches:
               jobs.append(pool.submit(fetch, batch))
               time.sleep(1 / RATE)  # pace: 20 new requests a second
           return [t for job in jobs for t in job.result()]
   

For a full pipeline with ID files, resumable runs and CSV output, see how to rehydrate tweet IDs.

#Median, p90 and the slow tail

The median is the response time that half of the requests beat, and the 90th percentile (p90) is the time that 9 in 10 beat, so p90 predicts how a long job feels better than the average does. One slow request can pull an average far above what most requests see, while the median stays put.

The tail matters most where requests run one after another. A follower export follows its cursor page by page, so every slow page adds its full wait to the job. An AI agent that calls an API between steps waits on the slowest call in the chain. A batch job with many requests in flight hides most of the tail, because other requests keep running while one is slow.

Sample size decides how far down the tail a test can see. With 24 requests per task, the 95th and 99th percentiles are nearly the same request as the maximum, so an honest report shows the median, p90 and the maximum, and calls results within about 10% of each other a tie.

#What counts as an error in a Twitter API benchmark

An error is any request that doesn't return the data it asked for: a 4xx or 5xx status, a timeout, or a 200 whose body is empty or holds the wrong account or post. Tests that count only status codes miss the last kind, and on some APIs an empty page still costs money.

On Sorsa API, every error comes back as JSON with one message field, and the status tells you what to do next.

• 400

  What it means on Sorsa API

  The request is malformed

  What to do

  Fix the body or the parameters

• 401

  What it means on Sorsa API

  The API key is not valid

  What to do

  Copy the key again from the dashboard

• 403

  What it means on Sorsa API

  The key is missing, or the requests have run out

  What to do

  Send the ApiKey header, or add requests

• 404

  What it means on Sorsa API

  The account or post was not found

  What to do

  Check the username, ID or link

• 429

  What it means on Sorsa API

  More than 20 requests in one second

  What to do

  Wait a moment and retry

• 500

  What it means on Sorsa API

  A server error

  What to do

  Retry after a short pause

Failed requests are never charged on Sorsa API, so a retry after a 429 or a 500 costs only the request that succeeds. To see how many requests a key has left before a long job, GET /key-usage-info (opens in a new tab) returns the remaining balance and its expiry date, and that check is free. For every status the official X API returns, numbered codes included, see the X API error codes guide.

#What 99.9% uptime means in minutes

99.9% uptime allows about 43 minutes of downtime in a 30-day month, and 99.5% allows about 3.6 hours. The arithmetic is simple: a 30-day month has 720 hours, and 0.1% of them is about 43 minutes.

• 99.9%

  Downtime allowed in 30 days

  about 43 minutes

• 99.5%

  Downtime allowed in 30 days

  about 3.6 hours

• 99%

  Downtime allowed in 30 days

  about 7.2 hours

A one-day test can't measure uptime. It measures the share of its own requests that succeeded during that day, and a short outage either falls inside the test window or misses it. Uptime is a monthly figure, and it means most when it sits in a contract with a remedy attached.

Sorsa API's 99.9% uptime is guaranteed in its Terms of Service on every paid plan. If uptime in a month ever drops below 99.5%, Sorsa API adds bonus requests worth 10% of your monthly requests. An uptime figure on a home page with no terms behind it is a description, not a guarantee.

#How to judge a published Twitter API benchmark

Judge a published benchmark by its method before its numbers: who ran it, how many requests it timed, and whether every API got the same task at the same hour from the same place. Most Twitter API speed tests published in 2026 come from a vendor timing its own API, from one connection, within an hour or a day.

Eight questions sort a useful test from a marketing one:

1. Who ran it? A vendor can run a fair test, but the page should say it sells one of the APIs.

2. How many requests per task? A dozen calls show one moment. Hundreds of calls spread over a day show a pattern.

3. Did every API get the same inputs? The same accounts, posts and queries, in the same round.

4. Same place, same hours? One server, named by city and owner, with all APIs timed in the same hours.

5. Fresh or reused connections? Either is fine, but the test must say which.

6. Are failures counted? Errors, timeouts and 200s with empty or wrong data all belong in the success share.

7. Median and p90, or only an average? Averages hide the tail.

8. Can you check it? Per-request raw data, the provider's request IDs, or a hash of each response let anyone verify a number.

Speed tests of scraping services sit apart from data APIs. They time a rendered web page that still has to be parsed into fields, which is a different job from a REST call that returns JSON.

#Our open Twitter API benchmark: the method

We are preparing an open benchmark of Twitter/X data APIs, Sorsa API included, and we publish its method here before the run, so the rules can't bend to the result. Each API is tested the way a new developer meets it: one free account, no card, no paid priority.

• Tasks: a profile by username, a user's latest posts, a Latest search, and a post by ID, plus one job of 100 posts by ID done each API's best documented way.
• Schedule: 24 rounds, one at the start of each hour of one day, all from one server whose city and owner the report names.
• Inputs: a new public account, post and query in every round, the same for every API, with the APIs in random order.
• Timing: each request split into DNS, connect, TLS, first byte and total, with a 30-second timeout and no retries.
• Results: median, p90, maximum and success share per API and task, with close results called a tie.
• Evidence: every request with its time, status, timing, the provider's request ID and a SHA-256 hash of the response.
• Sorsa API's key: an ordinary free account, with no priority, no separate route and no cache for the test.
• The official X API: not measured, because X's Developer Policy forbids it; it is compared on published prices and limits instead.

The results will go on their own page on this site, and this article will link to it on the day they are published.

#Pick a Twitter API by job time, then by price

A Twitter API benchmark you can trust reports the median, p90 and success share for the same tasks on every API, and the job you run decides which of those numbers matters. For bulk reads, items per request and the rate limit set the pace: Sorsa API returns 100 tweets per request at 20 requests per second on every plan, up to 2,000 tweets a second, from $0.014 per 1,000 against $5.00 on the official X API. Start with the 100 free requests, which never expire, and see how the API fits the reads you run. Choosing on more than speed? Our guide on how to choose a Twitter API lays out the other checks.

#FAQ