TwitterAPI.io vs Sorsa: pay per item or a flat monthly plan, priced per data type

How each one bills

Both bills come down to requests × price per request, but the two services decide the price per request in opposite ways, and that difference matters more than any headline number.

Sorsa sells a monthly quota. Its pricing page (api.sorsa.io/pricing) lists three plans: Starter at $49 a month for 10,000 requests, Pro at $199 for 100,000 and Enterprise at $899 for 500,000, with 16% off for yearly billing and custom plans above that. “One API call is one request, on every endpoint and every plan.” A search that finds nothing is one request; so is a single profile lookup or a single follow check. Requests that return an error are not deducted. Its docs (docs.sorsa.io/pricing) put the price per request at $0.0049 on Starter, $0.00199 on Pro and $0.0018 on Enterprise, but that is the price only if you use the whole plan: the plan fee is fixed, so half a plan used means each request cost twice as much, and requests left at the end of the period are not refunded.

TwitterAPI.io uses credits with no plan required: 100,000 credits are $1. Tweets cost 15 credits each, on search, replies, mentions, timelines and lookups by ID alike, with a 15-credit minimum per request and no per-request cap. Profiles are 18 credits each, or 1 credit each when a batch request returns 100 or more; followers are 1 credit each at 200 per page; a page of 20 verified followers is 15 credits. Optional subscriptions convert the fee to credits and add extra on top: counting the first-month bonus plus 12 monthly returns, $1 buys 1.22× the credits on Builder ($99 a month) and 1.9× on Business ($1,499 a month).

request = max(15, 15 × tweets returned) credits · user search = 18 per user · 100,000 credits = $1

Put the two side by side and two things work in TwitterAPI.io's favour. First, most requests return little: a check that finds nothing costs $0.00015 here, under a tenth of a fully used Pro request, and a request that returns up to 11 tweets costs less here than on any fully used Sorsa plan. Second, TwitterAPI.io charges only for what you call, while a Sorsa plan is a fixed fee whatever you use. The chart prices the average request in five workloads on our customers' request mix, against one request on Sorsa's $199 plan with all 100,000 requests used.

Price per data type

Sorsa prices below are shown Starter / Pro / Enterprise, each assuming you use the whole plan. Green marks the lower price on the row. “Business rates” assume our subscriptions, counting the first-month bonus plus 12 monthly returns, $1 buys 1.22× the credits on Builder ($99 a month) and 1.9× on Business ($1,499 a month).

Items per request: about 20 for Sorsa search, mentions and replies; up to 100 for its bulk profile lookups; up to 200 for verified followers (from its pricing docs (docs.sorsa.io/pricing)). TwitterAPI.io returns up to 20 tweets per search page and 20 verified followers per page. TwitterAPI.io prices from our pricing page; Sorsa prices from its pricing page (api.sorsa.io/pricing) and docs, checked in 2026.

Reading the table

A monitoring check that finds nothing costs $0.00015 here, under a tenth of a request on a fully used Pro plan, and most monitoring checks find nothing. A search that returns a few tweets stays lower too: up to 11 tweets, one request here costs less than one request on any fully used Sorsa plan. The same per-tweet rule applies to replies, quotes, mentions and list polls. Profiles are lower both ways: single lookups at $0.00018, and batches of 100 or more at $0.01 per 1,000. Verified followers cost $0.00015 for a page of 20 here, $0.0075 per 1,000, under Sorsa's $0.009 on Enterprise, and a follow check costs $0.001.

Tweet details by ID: pay for the tweets you fetch

If your pipeline already has tweet IDs (from a dataset, past results, or links people submit) and needs fresh metrics, TwitterAPI.io's /twitter/tweets endpoint takes a comma-separated list of IDs and bills per tweet returned. On our customers' mix the average request costs $0.000389 ($0.000205 on the Business plan), against $0.00199 for one request on a fully used Sorsa Pro plan. This is the batched call, with 429 handling:

import os, time, requests

KEY = os.environ["TWITTERAPI_IO_KEY"]

def get_tweets(ids):
    """Fetch tweets by ID in chunks (100 here; check the documented maximum)."""
    out = []
    for i in range(0, len(ids), 100):
        chunk = ",".join(ids[i:i + 100])
        for attempt in range(6):
            r = requests.get("https://api.twitterapi.io/twitter/tweets",
                             headers={"X-API-Key": KEY},
                             params={"tweet_ids": chunk}, timeout=30)
            if r.status_code != 429 or attempt == 5:
                break
            time.sleep(2 ** attempt)  # back off on 429
        r.raise_for_status()
        out.extend(r.json().get("tweets", []))
    return out  # billed per tweet: 1,000 tweets = $0.15

What a month costs: seven workloads

Plan pricing only means something against a real month of work. These seven jobs are costed on both, with the arithmetic shown. Three of them come straight from Sorsa's own documentation and blog, so you can check that we used its assumptions. Sorsa is priced at the smallest plan that covers the requests; TwitterAPI.io at pay-as-you-go rates.

Keyword alert polled every 30 seconds (Sorsa's own example)

86,400 checks a month; 90% find nothing, 10% find 3 tweets

TwitterAPI.io77,760 × $0.00015 + 8,640 × $0.00045 = $15.55

Sorsa86,400 requests: Pro plan, $199

Research backfill, 1 million tweets by keyword

50,000 full search pages

TwitterAPI.io50,000 × $0.003 = $150.00

Sorsa50,000 requests: Pro plan, $199 (Starter's 10,000 is too small; half of Pro goes unused)

Competitor analysis, 5 accounts weekly (Sorsa's own example)

per run: 5 profiles, 250 timeline pages, 50 mention pages, all pages full; 4 runs

TwitterAPI.io4 × (5 × $0.00018 + 250 × $0.003 + 50 × $0.003) = $3.60

Sorsa1,220 requests: Starter plan, $49

200 accounts in an X List, checked every 5 minutes

8,640 list polls a month

TwitterAPI.io$1.30 if every poll is empty, $25.92 if every poll returns a full page

Sorsa8,640 requests: Starter plan, $49

Enrich 100,000 profiles

by user ID, 100 per request on both

TwitterAPI.io100,000 × $0.00001 = $1.00

Sorsa1,000 requests: Starter plan, $49

Export 1 million followers

200 per page on both

TwitterAPI.io5,000 pages × $0.002 = $10.00

Sorsa5,000 requests: Starter plan, $49

Real-time feed of 6 fixed accounts

push here; on Sorsa, one list poll a minute to approach push latency (a 5-minute poll, 8,640 requests, fits Starter at $49)

TwitterAPI.ioTwitter Stream Starter: $29.00

Sorsa43,200 requests: Pro plan, $199

These jobs share a shape: polling, profiles, followers, push delivery, or a volume that leaves most of a Sorsa plan unused. Sorsa's own 30-second keyword monitor is the sharpest case: 86,400 requests need its $199 Pro plan, while the same checks cost $15.55 here, because nine in ten find nothing. A 1-million-tweet backfill on full pages costs $150.00 here against $199, because it needs Pro and uses half of it. Sorsa's weekly competitor analysis comes to $3.60 here against Starter's $49.

The plan-fit question

A flat plan is a bet that your month will look like the plan. Sorsa's per-request prices assume you use every request before the period ends; whatever is left is gone. If you use 30,000 requests on Pro, you paid $199 for $59.70 of Pro-rate requests, about $0.0066 each. Up to about 66,334 requests a month (66% of Pro), even a full 20-tweet page here at $0.003 costs less than your effective Pro request; on Enterprise the same holds up to about 299,667 (60%), and on Starter, at $0.0049 a request, at any volume. For checks that return little or nothing the margin is far wider. Sorsa's own pricing calculator is candid about the low end too: it notes that below roughly 10,000 reads a month the official pay-per-use API is cheaper than its plans.

Features and limits

Sorsa figures from its pricing (api.sorsa.io/pricing), rate-limit (docs.sorsa.io/rate-limits), authentication (docs.sorsa.io/authentication), error-code (docs.sorsa.io/error-codes) and real-time monitoring (docs.sorsa.io/real-time-monitoring) pages and its docs index (docs.sorsa.io/llms.txt); TwitterAPI.io from our pricing and rate limits pages. Checked in 2026.

Rate limits in practice

Sorsa limits every key to 20 requests per second on every plan, counted per second rather than in a sliding window, and returns 429 for the excess with no rate-limit headers. TwitterAPI.io starts new, unpaid accounts at 0.2 requests per second, raises every account to 20 after the first payment, and goes to 50 on the Scale subscription and 500 on Business, answering 429 when you go over (no Retry-After header, so back off about a second and retry).

Real-time delivery

Sorsa has no webhooks or streams. Its real-time guide (docs.sorsa.io/real-time-monitoring) describes polling every 1 to 30 seconds and suggests putting up to 5,000 accounts in an X List and polling the list, so one request covers them all. That is a smart pattern, and it works here too: our /twitter/list/tweets is billed per tweet returned, $0.00015 for a poll that finds nothing. The difference is cost per poll and who does the polling. On Sorsa every poll spends a request from the plan, whatever it returns; here an empty poll costs $0.00015, and you can skip polling altogether: keyword filter rules run on our side and push matches by webhook or WebSocket at the polling price (see the webhooks guide), and Twitter Stream pushes new posts from a fixed account list from $29 a month for 6 accounts.

Write actions and agents

Sorsa is read-only by design. TwitterAPI.io offers posting, likes, retweets, follows and DMs through an X account you log in with (login cookies plus a proxy), which is what you need for a bot or a scheduling tool and what you should avoid giving an unattended agent. For agents, our MCP server is read-only, open source (MIT) and runs locally with npx, with 12 tools for search, users, followers, replies and trends.

The same request on both

The two APIs look different on the wire. Sorsa uses a versioned base URL, an ApiKey header and, for search, timelines, replies and quotes, a POST with a JSON body. TwitterAPI.io uses /twitter/... paths, an X-API-Key header and GET with query parameters. Here is the same search:

# TwitterAPI.io
curl -H "X-API-Key: $TWITTERAPI_IO_KEY" \
  "https://api.twitterapi.io/twitter/tweet/advanced_search?query=from%3Anasa&queryType=Latest"

# Sorsa
curl -X POST "https://api.sorsa.io/v3/search-tweets" \
  -H "ApiKey: $SORSA_KEY" -H "Content-Type: application/json" \
  -d '{"query": "from:nasa", "order": "latest"}'

Request and response fields

Endpoint map

Sorsa paths and fields from its API reference (docs.sorsa.io/llms.txt) and pagination guide (docs.sorsa.io/pagination). Compare the objects of each endpoint you use before moving production traffic.

One adapter for either provider

While you migrate, or if you run both side by side for a while, keep the differences in one place. This TypeScript generator pages through a search on either service, returns one tweet shape, backs off and retries on 429, and throws a clear error when a Sorsa quota runs out (403):

// Search on either provider and get the same tweet shape back.
// Sorsa: POST JSON, cursor in the body, end of results = no next_cursor.
// TwitterAPI.io: GET query string, cursor param, end of results = has_next_page false.
type Provider = "twitterapi.io" | "sorsa"
type Tweet = { id: string; text: string; createdAt: string; likes: number; author: string }

const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms))

async function call(provider: Provider, key: string, query: string, cursor: string) {
  for (let attempt = 0; ; attempt++) {
    const res = provider === "twitterapi.io"
      ? await fetch(
          "https://api.twitterapi.io/twitter/tweet/advanced_search?" +
            new URLSearchParams({ query, queryType: "Latest", ...(cursor ? { cursor } : {}) }),
          { headers: { "X-API-Key": key } },
        )
      : await fetch("https://api.sorsa.io/v3/search-tweets", {
          method: "POST",
          headers: { ApiKey: key, "Content-Type": "application/json" },
          body: JSON.stringify({ query, order: "latest", ...(cursor ? { next_cursor: cursor } : {}) }),
        })
    if (res.status === 429 && attempt < 5) {
      await sleep(1000 * 2 ** attempt) // back off, then retry
      continue
    }
    if (res.status === 403 && provider === "sorsa") throw new Error("sorsa: quota used up or key not allowed")
    if (!res.ok) throw new Error(`${provider} ${res.status}`)
    return res.json()
  }
}

function normalize(provider: Provider, t: any): Tweet {
  return provider === "twitterapi.io"
    ? { id: t.id, text: t.text, createdAt: t.createdAt, likes: t.likeCount, author: t.author?.userName }
    : { id: t.id, text: t.full_text, createdAt: t.created_at, likes: t.likes_count, author: t.user?.username }
}

export async function* searchTweets(provider: Provider, key: string, query: string, maxPages = 10) {
  let cursor = ""
  for (let page = 0; page < maxPages; page++) {
    const body = await call(provider, key, query, cursor)
    for (const t of body.tweets ?? []) yield normalize(provider, t)
    const next = body.next_cursor
    const more = provider === "twitterapi.io" ? Boolean(body.has_next_page) && Boolean(next) : Boolean(next)
    if (!more) return
    cursor = next
  }
}

Switching checklist

1. Export a month of Sorsa usage (its key-usage endpoint and usage page show requests used) and split it by endpoint. Price each line with the table above, and note how much of your plan you actually use.
2. Split search-type calls by what they return. Empty and small results are where the savings are largest.
3. Replace POST bodies with query parameters, ApiKey with X-API-Key, and the end-of-results check with has_next_page.
4. Rename fields in your parser (full_text → text, likes_count → likeCount, user → author) or use the adapter above.
5. If you pass tweet URLs to Sorsa, extract the IDs; our endpoints take IDs only (replies, tweets by ID).
6. If you poll, decide whether to keep polling (empty polls cost $0.00015) or move keyword rules to webhook or WebSocket delivery.
7. Make a first payment before load testing; unpaid accounts are limited to 0.2 requests a second.
8. Run both in parallel on the free tiers ($1 here if the account passes the invisible bot check (one per person and network), 100 requests there) and compare row counts and bills before cutting over.

Price your own workload

The calculator from our Twitter API price comparison, with Sorsa highlighted. Enter how many searches you run, how many tweets they usually return and the request rate you need; Sorsa is priced at the smallest plan that covers the calls. It models search and profiles. If most of your requests return full pages of tweets (bulk exports, full timelines), compare the per-page price for your volume; on the Business plan a 20-tweet page costs $0.0016 after 12 monthly payments ($0.002 in the first month). For the full rate cards see Twitter API pricing.

What Sorsa's pages say about us, checked

Sorsa has no dedicated page about TwitterAPI.io, but its pricing page (api.sorsa.io/pricing), its Twitter API alternatives (api.sorsa.io/blog/twitter-api-alternative) roundup, its scrapers roundup (api.sorsa.io/blog/twitter-scrapers) and its MCP post (api.sorsa.io/blog/twitter-mcp-server) all describe us. Most of it is fair; a couple of figures are out of date.

Both against the official X API

Both services exist because of what the official API costs. X now bills per resource read with no subscriptions: according to its pricing documentation, $0.005 per post read, $0.010 per user read and $0.010 per follower or following read; creating a post costs $0.015, or $0.20 if it contains a URL. Pay-per-use is capped at 3 million post reads per monthly billing cycle, above which you need an Enterprise agreement. New accounts get $20 of credits when they save a first eligible card, plus a match of the first auto-recharge up to $50.

The official API still makes sense when you need a contract with X, posting through X's own consent screen, or data only an authenticated first-party app can read. For reading public posts in volume, either service costs a small fraction of the official price. See TwitterAPI.io vs the official X API for the full comparison.

Quick decision guide