---
title: "Twitter Scraper API Cost Per Job: The Real Rate Card"
description: "Price a twitter scraper api by the job, not the call. What 10,000 profiles, followers, replies and search results each bill, on live per-call rates."
canonical: https://www.twitterapis.com/blogs/twitter-scraper-api-cost-per-job-profiles-followers-replies
generator: md-live-route
generated: 2026-10-12T02:13:49.020Z
---

# Twitter Scraper API Cost Per Job: The Real Rate Card
1.  [Home](https://www.twitterapis.com/)
2.  / [Blog](https://www.twitterapis.com/blogs)
3.  / Twitter Scraper Api Cost Per Job Profiles Followers Replies

twitter scraper api twitter scraper api cost scrape twitter profiles scrape twitter followers twitter data pricing pay per call

 GUIDE

# What a Twitter Scraper API Bills Per Job: Profiles, Followers, Replies and Search

A rate card for twitter scraper api jobs by data type. What 10,000 profiles, followers, following, replies and search results each bill, on live rates.

Per our own spec, 65 of 112 endpoints bill $0.0008, 24 are free, and 23 sit between $0.0016 and $0.01. Every price ships inside our published OpenAPI document as an `x-cost-usd` field, so any figure in this post can be checked against the contract that bills it rather than taken on trust.

By [Emma](https://www.twitterapis.com/about/emma), developer relations at TwitterAPIs · October 6, 2026

Open in

Copy markdown [](https://x.com/intent/tweet?text=What%20a%20Twitter%20Scraper%20API%20Bills%20Per%20Job%3A%20Profiles%2C%20Followers%2C%20Replies%20and%20Search&url=https%3A%2F%2Fwww.twitterapis.com%2Fblogs%2Ftwitter-scraper-api-cost-per-job-profiles-followers-replies "Share \"What a Twitter Scraper API Bills Per Job: Profiles, Followers, Replies and Search\" on X")[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.twitterapis.com%2Fblogs%2Ftwitter-scraper-api-cost-per-job-profiles-followers-replies "Share \"What a Twitter Scraper API Bills Per Job: Profiles, Followers, Replies and Search\" on LinkedIn")

![A rate card for a twitter scraper api priced by data type: what 10,000 profiles, followers, following, replies and search results each bill on live rates](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-cover.webp "What a Twitter Scraper API Bills Per Job: Profiles, Followers, Replies and Search")

On this pagePrice the job, not the call 13 sections

Every twitter scraper api publishes a per-call rate. None of them publishes the one thing a buyer actually needs, which is what a job costs. A rate is a number per request. A job is "pull 10,000 profiles" or "grab the followers of these fifty accounts", and the distance between those two facts is where almost every scraping budget goes wrong. The rate is the easy part. The number of calls the job takes is the part nobody writes down, and it is set by how many items a single call hands back, which is different for every data type.

This post is the rate card nobody publishes. It prices six real jobs by data type, on live per-call rates, with the page size for each one measured against a real account rather than assumed. The headline is a seventy times spread across data types on a single read rate, and once you see where it comes from you can size any job in your head.

![Three headline figures from the scraper rate card: eighty cents per 1,000 profiles, less than a cent per 1,000 search results, and a seventy times spread on one read rate](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-01.svg)

One rate, a seventy times spread

> **TL;DR:** Price a scraping job by the data type, not the tweet count, because each endpoint returns a different number of items per billed call. On the standard $0.0008 read rate, 10,000 followers cost about $0.11, 10,000 search results about $0.40 at the default page or $0.08 at the largest, 10,000 replies about $0.20, and 10,000 profiles about $8.00. Full account history is the one premium read at $0.0024 a call, about $1.20 for 10,000 historic posts. Profiles are the expensive job because a profile call returns one account while a followers call returned 70 when measured, so the same rate bills seventy times as much per item. The free $0.50 signup credit buys 625 calls, which is 625 profiles or 43,750 followers.

## Price the job, not the call

A per-call rate prices a request. A job consumes a sequence of requests, and the number in that sequence is a property of the data, not of the price sheet. Ask what a read costs and the answer is one number. Ask what scraping 10,000 followers costs and you need a second number first, the one that says how many followers come back per call.

![Items returned per billed call by endpoint: one profile, twenty search results, forty-one replies, fifty-three following, seventy followers](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-02.svg)

What a single call hands back

That second number is the page size, and it is the whole game. A followers call returned 70 accounts when measured live. A profile lookup returns exactly one. On the same $0.0008 rate, that single fact makes 10,000 profiles cost seventy times what 10,000 followers cost. The rate is identical. The unit the endpoint returns per call is not, and that is what a rate card can never tell you on its own.

The pattern holds across every data type on the card, so the useful unit of analysis is a named job, "enrich these profiles", "pull this account's followers", "collect replies to this post", not an abstract thousand tweets. Our [per-call pricing walkthrough](https://www.twitterapis.com/blogs/twitter-api-cost) covers the rate itself, the [companion post on cost by workload](https://www.twitterapis.com/blogs/twitter-api-cost-by-workload-2026) runs this same method with a pipeline rather than a data type as the denominator, and the [cost of a one-million-tweet dataset](https://www.twitterapis.com/blogs/cost-of-1m-tweet-dataset-2026) prices raw tweet volume. This one prices jobs.

```python
# The whole model. Rate from the live per-endpoint cost table.
import math

READ = 0.0008          # standard read, every endpoint except full history
COMPLETE = 0.0024      # user/tweets/complete, the one premium read

def job_cost(items, items_per_call, rate=READ):
    calls = math.ceil(items / items_per_call)
    return calls, round(calls * rate, 4)

print(job_cost(10_000, 70))    # followers:  (143, 0.1144)
print(job_cost(10_000, 1))     # profiles:   (10000, 8.0)
print(job_cost(10_000, 20))    # search@20:  (500, 0.4)
```

## The rate card, by data type

Here is the card. Each row is a 10,000-item job, priced as calls times the live per-call rate, with the page size measured against a real account and stated beside it so you can swap in your own number and re-run the arithmetic for your own volume.

What a scraping job bills per data type, for a 10,000-item pull

| Data type (endpoint) | Items per call | Calls for 10,000 | Cost for 10,000 | Cost per 1,000 | Source |
| --- | --- | --- | --- | --- | --- |
| Search results (advanced\_search, page 20) | 20 | 500 | $0.4000 | $0.04000 | measured |
| Followers (user/followers) | 70 | 143 | $0.1144 | $0.01144 | measured |
| Following (user/following) | 53 | 189 | $0.1512 | $0.01512 | measured |
| Replies (tweet/replies) | 41 | 244 | $0.1952 | $0.01952 | measured |
| Profiles (user/info) | 1 | 10,000 | $8.0000 | $0.80000 | measured |
| Full history (user/tweets/complete) | 20 | 500 | $1.2000 | $0.12000 | derived |

as of 2026-10-06

Method: Page sizes measured live on 2026-10-06 with one real call per endpoint through the pay-per-call read API: a followers call returned 70 accounts, following 53, a search page 20, and a reply page 41 on a 3,064-reply post. Profiles are one account per call by design. Rates read from the live per-endpoint cost table at origin/main 1a6a84fc: every row is the standard $0.0008 read except full history, which is the $0.0024 premium tier. Cost is calls times rate, calls rounded up. Falsifiable by substituting your own measured page size and re-running the arithmetic.

![Six scraping jobs priced on the standard read rate, from profiles at eight dollars to search at eight cents per ten thousand items](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-03.svg)

The same volume, six very different bills

Three things in that table are worth reading slowly. Search is the cheapest per item because you set its page size yourself, anywhere from 1 to 100 results per call. Profiles are the most expensive by a wide margin because the lookup returns a single account and there is no page to spread the cost across. And full history is the only premium read on the card, three times the standard rate, because walking an account back to its first post is a heavier operation than reading a recent page.

Rate card

Cost per 1,000 items, by data type, on one read rate

| Point | Value |
| --- | --- |
| Profiles | 0.8 |
| Full history | 0.12 |
| Search, page 20 | 0.04 |
| Replies | 0.02 |
| Following | 0.015 |
| Followers | 0.011 |

Cost per 1,000 items in US dollars, each figure the billed rate divided by the measured items per call. The 70 times gap between profiles and followers sits on an identical $0.0008 read rate, so it is set by the page size alone. Measured 2026-10-06, rates at origin/main 1a6a84fc.

The bar makes the spread physical. Followers, following and replies all sit near the floor because they page well. Profiles tower over everything, on the same rate, purely because of the data model. If a vendor quotes you a flat per-call price and stops there, this is the chart they are not showing you.

## Where the calls actually go

Cost tracks calls, and calls track page size, so the honest way to see a scraping job is to count the calls it spends before the dollars it bills. The call count, not the rate, is the number the page size actually moves.

![Calls needed to pull 10,000 items by data type: 10,000 for profiles, 500 for search, 244 for replies, 189 for following, 143 for followers](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-05.svg)

Where the call count actually goes

Ten thousand followers is 143 calls. Ten thousand profiles is 10,000 calls. That is the entire story of the bill in two numbers. A job that reads accounts one at a time cannot amortise anything, so its call count equals its item count, while a job that pages spreads one call across dozens of items. The [rate limits guide](https://www.twitterapis.com/blogs/twitter-api-rate-limit-guide) covers how to pace those calls so a tight page-walk does not trip a limit, and the [best practices guide](https://www.twitterapis.com/blogs/twitterapis-best-practices) covers cursor handling and connection reuse.

```python
import requests

BASE = "https://api.twitterapis.com/twitter"

def page_followers(user_id, api_key, cursor=None):
    params = {"userId": user_id}
    if cursor:
        params["cursor"] = cursor
    r = requests.get(f"{BASE}/user/followers", params=params,
                     headers={"Authorization": f"Bearer {api_key}"}, timeout=30)
    r.raise_for_status()
    data = r.json()
    return data.get("users", []), data.get("next_cursor"), data.get("has_more")
```

That is the whole shape of a paging read: one call returns a page of users plus a cursor to the next page, and you walk it until `has_more` is false or you have enough. Each call is one billed read regardless of whether the page comes back full or half empty, which is why the page size you observe, not the one a doc promises, is the number that sets your bill.

## Profiles are the job to watch

If one line item blows up a twitter scraper api budget, it is almost always profiles, and for a reason that has nothing to do with the rate: a profile read returns exactly one account, so the job cannot spread a single call across more than one subject.

![The headline that profiles cost seventy times more per item than followers on an identical read rate because a profile call returns one account](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-07.svg)

The number that explains the card

A profile read returns exactly one account. There is no batch: a bulk by-ids lookup is not offered on the public read surface, so enriching a list means one call per handle, every time. That makes profile enrichment the one job where volume does not help you at all, and where the cost per subject has a hard floor the rate cannot lower. A real enrichment job shows the shape plainly.

Worked example

One enrichment job, sized before any code

Accounts to enrich: 25,000 · Total data cost: $20.20 · Share spent on profile reads: 99%

☑ 25,000 profile reads cost $20.00, one call each · ☑ Finding the 25,000 handles by search cost $0.20 at the largest page · ☑ Deduplicating handles before the profile reads is the only real saving · ☐ Deleted and protected accounts return nothing, billed or not

An illustration of a profile-enrichment job at a stated volume of 25,000 accounts, not a customer account. Profile reads dominate because they do not page. Derived from the live rates at origin/main 1a6a84fc on 2026-10-06.

Finding 25,000 handles by search costs about twenty cents at the largest page. Reading all 25,000 profiles costs twenty dollars, because that leg is one call each and pages nowhere. The only lever is to deduplicate your handle list before the profile reads, since every repeated handle you drop saves a whole call, and pulling clean handles out of free text for that set is a job for the [Python re module](https://docs.python.org/3/library/re.html). A developer who built a custom scraper for exactly this kind of account-level work described what it took to run:

> i spent three weeks building a custom twitter scraper for my ai agent. it broke constantly. rate limits. undocumented endpoint changes. pagination nightmares.
>
>, @RitOnchain [view on X](https://x.com/RitOnchain/status/2058059097174364395)

That is the build-it-yourself tax, and it is why most teams reach for a read API with the pagination already handled. If you are weighing the two, the [build versus buy comparison](https://www.twitterapis.com/blogs/best-twitter-api-for-scraping) lays out where each one wins.

```python
# Profiles do not batch: one call per handle. Dedupe first.
def enrich(handles, api_key):
    seen, out = set(), []
    for h in handles:
        key = h.lower()
        if key in seen:        # a repeat handle would bill a second time
            continue
        seen.add(key)
        r = requests.get(f"{BASE}/user/info", params={"userName": h},
                         headers={"Authorization": f"Bearer {api_key}"}, timeout=10)
        r.raise_for_status()
        out.append(r.json().get("user"))
    return out
```

### Start building with TwitterAPIs

$0.0008 a call, about $0.04 per 1,000 tweets at 20 tweets a page. $0.50 free credits. No credit card required.

[Get API Key](https://www.twitterapis.com/signup)[View Pricing](https://www.twitterapis.com/pricing)

## Search is the cheapest, if you set the page

Search is the one endpoint where you set the page size yourself, anywhere from 1 to 100 results per call, and that single piece of control is exactly why it is the cheapest data type per item on the entire rate card.

![Search cost per 1,000 results at a page of twenty against a page of one hundred, four cents against under one cent](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-13.svg)

The page size you choose on search

The search endpoint takes a count between 1 and 100. At the default of 20, a 10,000-result job is 500 calls and about $0.40. Ask for 100 results a call and the same job is 100 calls and about $0.08, which is $0.008 per 1,000. The result fields are identical either way, so leaving the count at its default is simply paying five times more for the same data. The [advanced search operators reference](https://www.twitterapis.com/blogs/twitter-advanced-search-operators) lists every filter you can combine to keep each page relevant, and the [complete API tutorial](https://www.twitterapis.com/blogs/twitter-api-tutorial-2026-complete-guide) covers the request model the snippet below assumes.

```bash
# Set the page to 100 on search. query= and product=, not q= or type=.
curl "https://api.twitterapis.com/twitter/tweet/advanced_search?query=%22contract%20address%22%20lang%3Aen&product=Latest&count=100" \
  -H "Authorization: Bearer $TWITTERAPIS_KEY"
```

```python
def search_page(query, api_key, cursor=None):
    params = {"query": query, "product": "Latest", "count": 100}
    if cursor:
        params["cursor"] = cursor
    r = requests.get(f"{BASE}/tweet/advanced_search", params=params,
                     headers={"Authorization": f"Bearer {api_key}"}, timeout=10)
    r.raise_for_status()
    data = r.json()
    return data.get("tweets", []), data.get("next_cursor")
```

The pain that pushes people to a read API in the first place is usually the official price per tweet, not the scraping itself. One account doing automation work put the problem in a single line:

> The official API charges $5+ per 1,000 tweets. That's prohibitive at scale.
>
>, @proxystackpro [view on X](https://x.com/proxystackpro/status/2085415689607655457)

Against that, $0.04 per 1,000 search results at the default page, or $0.008 at the largest, is the gap the whole rate card is built on. The [cheapest Twitter API comparison](https://www.twitterapis.com/blogs/cheapest-twitter-api-2026-8-providers-ranked-by-real-per-1000-tweet-cost) and the [cost benchmark](https://www.twitterapis.com/blogs/twitter-api-cost-benchmark-2026) put those numbers next to other providers, the [X API pricing change breakdown](https://www.twitterapis.com/blogs/x-api-pricing-change-2026) tracks how the official read model shifted, and the [X developer documentation](https://docs.x.com/x-api/introduction) catalogues which reads the official API exposes.

## Full history is the one premium read

Most reads on the card bill at the standard $0.0008 rate, and exactly one does not: a full account history is the single premium read, priced at $0.0024 a call because walking an account all the way back to its first post is a heavier operation than reading one recent page.

![Cost per 1,000 tweets for recent timeline reads, search results, and full account history, showing history at the premium rate](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-11.svg)

Recent is cheap, history is premium

Pulling a complete account history runs through a dedicated endpoint at $0.0024 a call, three times the standard read, because the operation walks an account back to its earliest posts rather than returning a recent page. A recent-timeline read of the same account bills at the ordinary $0.0008. So 10,000 historic tweets cost about $1.20 while 10,000 recent ones cost about $0.40. The practical rule is to never run a full backfill on a schedule: store the newest post id after the first pull, then read incrementally against it, so you pay the premium once rather than every cycle. The [full account history guide](https://www.twitterapis.com/blogs/scrape-tweet-history-api-2026) covers the pagination, and the [fetch-a-full-thread guide](https://www.twitterapis.com/blogs/fetch-full-twitter-thread-api-2026) covers the related conversation walk.

## The data model, not the price

Lay the data types side by side and the pattern that runs through the whole rate card is visible at once: every difference in the cost column comes from how many items an endpoint returns per call, not from the rate it charges per call.

The data model

Why the same rate bills so differently by data type

|  | Profiles | Followers | Search | Full history |
| --- | --- | --- | --- | --- |
| Items per call | 1 | 70 | 20 to 100 | 20 per page |
| Does it page? | No | Yes | Yes, you set it | Yes, many pages |
| Billed rate | $0.0008 | $0.0008 | $0.0008 | $0.0024 |
| Cost per 1,000 | $0.80 | $0.0114 | $0.008 to $0.04 | $0.12 |
| Cheapest lever | Deduplicate first | Nothing, already cheap | Request page 100 | Backfill once, increment |

A comparison of how the data model, not the price, moves the bill. Each cell uses the measured page sizes and the live rates from this post. Written 2026-10-06.

Every difference in the cost column comes from the "items per call" row, not the "billed rate" row. Four of the six jobs sit on an identical $0.0008 rate and still span two orders of magnitude, because one returns a single account and another returns a page of seventy. This is why a per-call price, quoted alone, cannot answer a buyer's real question, and why a worked job always beats a rate sheet.

![A grid of five data types showing items returned per call, whether the endpoint pages, and the cost per 1,000 items](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-08.svg)

Does the endpoint page, or not

The developers who feel this most are the ones who tried to build the collection layer themselves and hit the page-walk and the rate limits before they ever got to cost. The theme runs through the web-scraping community, where the realistic view of what scraping actually costs to run is a recurring thread:

> [Enterprise Web Scraping: What to look out for](https://reddit.com/r/webscraping/comments/1aosgks/enterprise_web_scraping_what_to_look_out_for/) from [r/webscraping](https://www.reddit.com/r/webscraping/)

A read API moves those three fixes, the pagination, the rate-limit handling, and the per-item billing, off your plate and onto a documented endpoint. This walkthrough on pulling structured data out of Twitter with Python mirrors the extract-and-page loop the snippets above use:

[https://www.youtube.com/watch?v=3KaffTIZ5II](https://www.youtube.com/watch?v=3KaffTIZ5II)

## Measure the page size, never assume it

Every number on this rate card rests on one measured value per endpoint, the page size, and it is the single number you should verify for yourself against a real account before you trust any cost estimate you build on top of it.

![Three steps to measure a page size live before trusting it: call the endpoint once, count the items in the response, divide the target by that number](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-10.svg)

Measure the page before you trust it

Page sizes are not round and they are not promised accurately in most docs. The followers endpoint returned 70 accounts on a measured call, following returned 53, and a reply page returned 41 on a 3,064-reply post. None of those is a number you would have guessed. So the discipline is simple: make one real call to the endpoint you plan to use, against an account the size of the ones you will actually read, and count the items in the response. That observed page size, divided into your target, is your call count, and everything else follows.

![Four steps that turn a per-call rate into a job bill: pick the endpoint, measure its page size, divide the target by it, multiply calls by the rate](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-04.svg)

Rate to bill in four steps

```python
# Measure a page size live, then price the job. Never assume the page.
def measured_page(endpoint, params, api_key, items_key):
    r = requests.get(f"{BASE}/{endpoint}", params=params,
                     headers={"Authorization": f"Bearer {api_key}"}, timeout=30)
    r.raise_for_status()
    return len(r.json().get(items_key, []))

# e.g. measured_page("user/followers", {"userName": "someaccount"}, key, "users") -> 70
```

The [Python requests library](https://requests.readthedocs.io/en/latest/) documents the client, the [pagination reference](https://en.wikipedia.org/wiki/Pagination) covers the cursor model, and [X's own pricing page](https://docs.x.com/x-api/getting-started/pricing) is the comparison baseline for the official rates quoted above. The read endpoints behave as ordinary [stateless REST resources](https://en.wikipedia.org/wiki/Representational_state_transfer), which is what lets a job size its calls deterministically before a line of code runs.

### The cheapest pay-as-you-go Twitter API. Try it free.

$0.0008 a call, about $0.04 per 1,000 tweets at 20 tweets a page. $0.50 free credits. No credit card required.

[Start Free](https://www.twitterapis.com/signup)[Cost Calculator](https://www.twitterapis.com/twitter-api-cost-calculator)

## What the free credit really buys

Because the data type sets the bill, the free signup credit buys wildly different amounts of data depending on which endpoint you point it at, and the range across data types is really just the rate card restated as one spendable number.

![How far the fifty cent free credit goes: 625 profiles, 12,500 search results, 43,750 followers](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-06.svg)

One credit, three very different answers

The $0.50 credit is 625 standard calls. Spend those 625 calls on profiles and you get 625 accounts. Spend them on search at the default page and you get 12,500 results. Spend them on followers and you get 43,750. That range, from 625 to 43,750 on one credit, is the rate card restated as a single number, and it is enough to size and dry-run any job end to end before you add a card. Grab a key on the [sign up](https://www.twitterapis.com/signup) page and model the spend first with the [cost calculator](https://www.twitterapis.com/twitter-api-cost-calculator), which does this arithmetic for you.

## The levers that actually move the bill

Four levers cut a twitter scraper api bill, and every one of them works on the call count rather than the rate, because the call count is the only term in the job you actually control once you have picked the endpoint.

![Four levers that cut a scraping bill: request the largest page, deduplicate before per-item reads, cap the page walk, keep history off a schedule](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-14.svg)

Four levers that move the bill

Request the largest page on any endpoint that lets you, which in practice means setting search to 100. Deduplicate your subject list before any per-item read, because on profiles and replies every duplicate you drop is a whole call saved. Cap the page-walk at the sample you actually need rather than draining every cursor out of habit. And keep full history off a schedule, backfilling once and reading incrementally after. Social-media collection scripts that ignore these are exactly the ones that surprise their owners with a bill, a pattern the scraping community sees constantly:

> [Easy Social Media Scraping Script \[ X, Instagram, Tiktok, Youtube \]](https://reddit.com/r/webscraping/comments/1h221ow/easy_social_media_scraping_script_x_instagram/) from [r/webscraping](https://www.reddit.com/r/webscraping/)

```python
# Retry a rate-limited call rather than letting it drop a page.
import time

def get_with_retry(endpoint, params, api_key, tries=4):
    for attempt in range(tries):
        r = requests.get(f"{BASE}/{endpoint}", params=params,
                         headers={"Authorization": f"Bearer {api_key}"}, timeout=30)
        if r.status_code == 429:
            wait = int(r.headers.get("Retry-After", 2 ** attempt))
            time.sleep(wait)
            continue
        r.raise_for_status()
        return r.json()
    return {}
```

A rate limit arrives as HTTP 429, and the [MDN reference for 429](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429) describes the `Retry-After` header worth honouring when present. Pacing is a frequency cap set independently of price, so a dense page-walk has to [rate-limit itself](https://en.wikipedia.org/wiki/Rate_limiting) rather than assume every call lands instantly.

## What no budget can buy

Not every line in a scraping plan can be priced, because some of the data a plan quietly assumes does not exist at any rate, and the honest move is to record those as unknown rather than hand them a plausible number that reads as fact.

What no public Twitter data API returns at any price, recorded rather than priced

| What a plan often assumes | Reality | Provenance | Source |
| --- | --- | --- | --- |
| Deleted posts can be pulled for a fee | Gone rather than expensive | unknown | unknown |
| Protected accounts are readable on a higher tier | Not readable through a public API by design | published | published |
| Historic engagement counts can be backfilled | Only current values return; snapshots must be recorded as you go | unknown | unknown |
| Paid reach and ad spend are exposed | Not part of the public data surface | unknown | unknown |

as of 2026-10-06

Method: Compiled from the public documentation surface and from what the read endpoints return. Three rows are tagged unknown because they describe an absence, which can only be observed not to appear, never measured. Falsifiable by anyone producing the field from a public endpoint.

![Four things no public Twitter data API returns at any price: deleted posts, protected accounts, historic engagement snapshots, and paid reach](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-09.svg)

Four things no budget can buy

Deleted posts are gone, not expensive. Protected accounts are not readable through a public API by design. Historic engagement counts as they stood at a past moment are not recoverable after the fact, only the current values, which is why any longitudinal study has to snapshot as it goes. Recording those as unknown, rather than giving them a plausible number, is the difference between a plan that survives contact with the data and one that gets rewritten in month two. If you are extracting signal rather than raw rows, the [sentiment analysis tutorial](https://www.twitterapis.com/blogs/twitter-sentiment-analysis-python) and the [bot detection guide](https://www.twitterapis.com/blogs/twitter-bot-detection-guide) run on the same reads priced here.

## Six ways the estimate goes wrong

The same sizing mistakes recur across scraping jobs, and each one carries a measurable price, almost always because it misreads the page size or the unit an endpoint returns rather than the rate the vendor charges for a call.

![Six recurring mistakes in sizing a Twitter scraping job and what each one costs](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-15.svg)

Six ways the estimate goes wrong

Assuming one call per item on a paged endpoint overstates the bill and hides the real lever. Assuming a round page size understates it, because the observed pages are 70 and 53 and 41, not 100. Leaving search at its default page pays five times over. Running history on a schedule pays the premium rate repeatedly for posts you already have. Skipping deduplication bills every repeat handle twice. And treating an unknown as a zero ships a plan with a hole in it. The [migration guide](https://www.twitterapis.com/blogs/migrate-from-twitterapi-io-to-twitterapis) and the [getting-a-key walkthrough](https://www.twitterapis.com/blogs/how-to-get-twitter-api-key) cover the setup once the sizing is right, and the [Node.js tutorial](https://www.twitterapis.com/blogs/twitter-api-nodejs-tutorial) mirrors the Python here.

![Why profiles are the costly job: eight dollars for 10,000 of them, one account per call, seventy times the per-item cost of followers](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-12.svg)

The one job with no page to amortise

## From rate to bill in one line

A twitter scraper api is priced per call, but you buy jobs, and the translation is one line of arithmetic: items divided by the page size, times the rate for the endpoint.

![The whole method in three numbers: items divided by page size times rate equals the job bill](https://www.twitterapis.com/blog/content/images/twitter-scraper-api-cost-per-job-profiles-followers-replies-slot-16.svg)

The whole rate card in one line

Measure the page size once, against a real account, and the rest is multiplication you can do before any code exists. The data type decides the bill far more than the vendor does, because the page size is a property of the endpoint and the rate is almost always the same $0.0008. Size the job, pick the largest page, deduplicate the subjects, and keep history off a schedule. Then [sign up](https://www.twitterapis.com/signup), model it on the [pricing page](https://www.twitterapis.com/pricing), and run the real numbers against the free credit before you commit a budget. The [API reference](https://www.twitterapis.com/blogs/twitter-api-reference) lists every endpoint priced here with its parameters and response shape.

On this page

-   Price the job, not the call
-   The rate card, by data type
-   Where the calls actually go
-   Profiles are the job to watch
-   Search is the cheapest, if you set the page
-   Full history is the one premium read
-   The data model, not the price
-   Measure the page size, never assume it
-   What the free credit really buys
-   The levers that actually move the bill
-   What no budget can buy
-   Six ways the estimate goes wrong
-   From rate to bill in one line

// sources

## Where these numbers come from

Each row is a figure in this post and the artefact it was read from. Prices and limits on this platform move, so check the date on the source before you plan against it.

[X API published pricing](https://docs.x.com/x-api/getting-started/pricing)

Source of the official comparison rate for the same reads, which confirms a pay-per-usage model and lets a reader set the third-party per-call figures against the standard $0.0008 read used throughout this post.

[X developer documentation](https://docs.x.com/x-api/introduction)

Backs the account of which reads the official API exposes and under what access model, the baseline the per-job rate card is measured against.

[Python requests library](https://requests.readthedocs.io/en/latest/)

Documents the HTTP client every code sample uses, including the session reuse and raise\_for\_status behaviour the pagination and retry snippets rely on.

[Python re module](https://docs.python.org/3/library/re.html)

Backs the handle and id extraction in the deduplication snippet, where a set of seen ids stops one account being billed for twice across overlapping pages.

[MDN HTTP 429 reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429)

Backs the retry layer, that a rate limit arrives as HTTP 429 and carries a Retry-After header worth honouring, with exponential backoff as the fallback.

[Pagination reference](https://en.wikipedia.org/wiki/Pagination)

Supplies the definition of cursor pagination behind the page-walk model, where each call returns a page plus a cursor to the next, which is what makes a page size the unit that sets the bill.

[Representational state transfer reference](https://en.wikipedia.org/wiki/Representational_state_transfer)

Backs the description of the read endpoints as stateless REST resources returning structured JSON, the property that lets a job size its calls deterministically.

[Rate limiting reference](https://en.wikipedia.org/wiki/Rate_limiting)

Backs the point that a provider caps request frequency independently of price, so a page-walk has to pace itself rather than assume every call lands instantly.

## Frequently Asked Questions

### How much does a Twitter scraper API cost per job?

It depends on the data type, not the tweet count, because each endpoint returns a different number of items per billed call. On the standard $0.0008 read rate, pulling 10,000 followers costs about $0.11, 10,000 search results about $0.40 at the default page, and 10,000 profiles about $8.00. The spread is 70 times on one rate, and it is set entirely by how many items a single call returns. Profiles are the expensive one because a profile lookup returns exactly one account, while a followers call returned 70 accounts when measured.

### How do I calculate my own Twitter scraping bill?

Multiply three numbers: the items you need, divided by the items one call returns, times the billed rate for that endpoint. Ten thousand replies at 41 replies per call is 244 calls, and at $0.0008 that is about $0.20. The only number people guess wrong is the middle one, the page size, so measure it live against the account you will actually read rather than assuming a round figure. Search is capped by the count you request, between 1 and 100, so you set that page size yourself.

### How far does the free signup credit go for scraping?

The $0.50 signup credit buys 625 standard calls, and what that is worth depends entirely on the data type. It covers about 625 profiles, 12,500 search results at the default page, 25,625 replies, 33,125 following and 43,750 followers, because each of those spends the same 625 calls across a different page size. That range, from 625 to 43,750 on one credit, is the clearest possible illustration that the data type decides the bill. It is enough to size any job end to end before you spend a cent.

### Why do profiles cost so much more than followers to scrape?

Because a profile lookup returns one account per call and a followers call returns a page of them. On a measured pull the followers endpoint returned 70 accounts in a single call and the following endpoint returned 53, while the profile endpoint returns exactly one. On the same $0.0008 rate that makes 10,000 profiles 70 times the price of 10,000 followers. The rate is identical. The unit the endpoint hands back per call is the whole difference, and no negotiation changes it because it is a property of the data model.

### What is the cheapest data type to scrape from Twitter?

Search results, when you request the largest page. The search endpoint lets you set a count between 1 and 100, so a job that asks for 100 results per call pulls 10,000 results in 100 calls for about $0.08, which is $0.008 per 1,000. At the default page of 20 the same 10,000 results take 500 calls and about $0.40. Nothing else on the rate card is cheaper per item, because every other endpoint has its page size fixed by the platform rather than set by you.

### Is a full account history more expensive than recent tweets?

Yes, and it is the one premium read on the card. Pulling a full account history runs through the complete-history endpoint at $0.0024 per call, three times the standard read rate, because walking an account back to its earliest posts is a heavier operation than reading a recent page. A recent-timeline read bills at the standard $0.0008. So 10,000 historic tweets cost about $1.20 against about $0.40 for the same volume of recent ones. Store a high-water mark after the first backfill and read incrementally against it so you never pay the premium rate twice for the same posts.

## Check out similar blogs

More guides on the Twitter/X API, scraping, and pricing.

[

![TwitterAPIs is live on Uneed: a pay-per-call Twitter API at $0.0008 a call with no X developer account, and what a launch day is worth to a developer API](https://www.twitterapis.com/blog/content/images/twitterapis-live-on-uneed-2026-cover.webp)

twitterapis uneed

### TwitterAPIs Is Live on Uneed: A $0.0008 Twitter API With No Developer Account

TwitterAPIs launched on Uneed today. What the pay-per-call Twitter API costs next to the official X API, how a Uneed launch day actually works, and what founders say one delivers.

Emma · Sep 29, 2026

](https://www.twitterapis.com/blogs/twitterapis-live-on-uneed-2026)[

![A Python crypto Twitter tracker that polls a list of KOL accounts, extracts EVM and Solana contract addresses from new posts and sends an alert, with the monthly bill for 25 and 100 accounts](https://www.twitterapis.com/blog/content/images/crypto-twitter-tracker-python-kol-contract-address-alerts-cover.webp)

crypto twitter tracker kol tracking

### Build a Crypto Twitter Tracker in Python: Watch a KOL List and Catch Contract Addresses

A runnable Python watcher that polls a named list of crypto accounts, pulls every new post, finds EVM and Solana addresses, and alerts you, with the monthly bill for 25 and 100 accounts.

Emma · Sep 28, 2026

](https://www.twitterapis.com/blogs/crypto-twitter-tracker-python-kol-contract-address-alerts)[

![What it costs to monitor a roster of fifty X accounts at each poll interval, with monthly billing, mean detection latency and cost per captured post](https://www.twitterapis.com/blog/content/images/x-account-monitoring-poll-cadence-cost-2026-cover.webp)

monitor twitter account x account monitoring cost

### Watching 50 X Accounts: What Every Poll Cadence Actually Bills

Every monitoring page sells you an interval and calls it real time. None of them prices it. Here is what a one minute, fifteen minute and daily poll across a fixed fifty account roster costs per month, and the route where the watch itself bills nothing.

Emma · Sep 12, 2026

](https://www.twitterapis.com/blogs/x-account-monitoring-poll-cadence-cost-2026)[

![Why X advanced search returns no results for posts that exist, with measured recall rates across 17 posts published between 2015 and 2026](https://www.twitterapis.com/blog/content/images/why-x-advanced-search-misses-posts-2026-cover.webp)

Twitter Advanced Search X API

### Why X Advanced Search Misses Posts You Know Exist (2026)

A query that returns nothing is not proof that nothing exists. We searched for 17 posts confirmed to exist, published between 2015 and 2026, and measured which query forms found them and which did not.

Emma · Sep 10, 2026

](https://www.twitterapis.com/blogs/why-x-advanced-search-misses-posts-2026)[

![X and Twitter platform statistics for 2026, showing which figures are measurable through a public API and which are not published by any source](https://www.twitterapis.com/blog/content/images/x-twitter-platform-statistics-2026-cover.webp)

twitter statistics x statistics

### X/Twitter Statistics in 2026: What an API Can Actually Measure, and What Nobody Can

Most X statistics roundups re-cite the same handful of numbers. We measured what a public API can and cannot see across 34 accounts, printed the query behind every figure, and traced the rest to their real sources.

Emma · Sep 10, 2026

](https://www.twitterapis.com/blogs/x-twitter-platform-statistics-2026)[

![One normalized X API price sheet for 2026 converting the official rate card and every third-party vendor to dollars per 1,000 tweets read and per 1,000 posts written](https://www.twitterapis.com/blog/content/images/twitter-api-pricing-in-2026-every-tier-and-every-alternative-on-one-price-sheet-cover.webp)

X API cost Twitter API pricing

### X API Cost in 2026: Every Tier and Alternative on One Sheet

X bills per resource in 2026. Here is every official rate and every vendor converted to one unit, dollars per 1,000 tweets, with a worked bill.

TwitterAPIs · Sep 9, 2026

](https://www.twitterapis.com/blogs/twitter-api-pricing-in-2026-every-tier-and-every-alternative-on-one-price-sheet)[

![Sprout Social, Brandwatch and a metered Twitter data API compared in one unit, dollars per 1,000 mentions retrieved, with every rate read from the vendor's own live pricing page in 2026](https://www.twitterapis.com/blog/content/images/twitterapis-vs-brandwatch-vs-sprout-social-what-you-pay-for-twitter-data-2026-cover.webp)

sprout social alternative brandwatch pricing

### Sprout Social Alternative 2026: What Twitter Data Really Costs

Sprout is $199 a seat. Brandwatch publishes no price. Here is what Twitter data costs per 1,000 mentions across all three, read live on 2026-09-09.

TwitterAPIs · Sep 9, 2026

](https://www.twitterapis.com/blogs/twitterapis-vs-brandwatch-vs-sprout-social-what-you-pay-for-twitter-data-2026)[

![Measured Twitter API failure distribution across 5.16 million production calls in 2026, broken down by status code, endpoint and week](https://www.twitterapis.com/blog/content/images/twitter-api-reliability-measured-2026-cover.webp)

twitter api error rate twitter api errors

### Twitter API Reliability, Measured: What Actually Fails Across 5.16 Million Calls

Every vendor publishes an uptime promise. Nobody publishes the failure distribution. Here is what broke across 5,155,699 production calls, by status code, by endpoint and by week.

Emma · Sep 2, 2026

](https://www.twitterapis.com/blogs/twitter-api-reliability-measured-2026)

[

TwitterAPIs ](https://www.twitterapis.com/)

The cheapest pay-as-you-go Twitter and X API. $0.0008 per call, which works out to $0.04 per 1,000 tweets on a full 20-tweet page. No subscriptions and no developer account.

## Product / API

-   [Pricing](https://www.twitterapis.com/pricing)
-   [Cost Calculator](https://www.twitterapis.com/twitter-api-cost-calculator)
-   [Rate Limits](https://www.twitterapis.com/twitter-api-rate-limits)
-   [MCP Server](https://www.twitterapis.com/mcp)
-   [Integrations](https://www.twitterapis.com/integrations)
-   [Language Clients](https://www.twitterapis.com/sdk)
-   [Changelog](https://www.twitterapis.com/changelog)
-   [Status](https://www.twitterapis.com/status)

## Developers

-   [Documentation](https://docs.twitterapis.com)
-   [API Reference](https://docs.twitterapis.com/docs/reference/search/tweet-advanced-search)
-   [User Info](https://docs.twitterapis.com/docs/reference/user-reads/user-info)
-   [User Tweets](https://docs.twitterapis.com/docs/reference/user-reads/user-tweets)
-   [Advanced Search](https://docs.twitterapis.com/docs/reference/search/tweet-advanced-search)
-   [Verified Followers](https://docs.twitterapis.com/docs/reference/follower-graph/user-verified-followers)

## Resources / Compare

-   [Answers](https://www.twitterapis.com/answers)
-   [Reviews](https://www.twitterapis.com/reviews)
-   [Free Tools](https://www.twitterapis.com/tools)
-   [Twitter ID Finder](https://www.twitterapis.com/tools/twitter-id-finder)
-   [Get a Twitter API Key](https://www.twitterapis.com/twitter-api-key)
-   [Official X API Comparison](https://www.twitterapis.com/twitter-api-pricing)
-   [Twitter API Use Cases](https://www.twitterapis.com/twitter-api-usecases)
-   [Twitter API Alternatives](https://www.twitterapis.com/twitter-api-alternatives)
-   [Twitter Unofficial API](https://www.twitterapis.com/twitter-unofficial-api)
-   [Twitter Free API](https://www.twitterapis.com/twitter-free-api)
-   [TwitterAPIs vs twitterapi.io](https://www.twitterapis.com/twitterapis-vs-twitterapi-io)
-   [TwitterAPIs vs GetXAPI](https://www.twitterapis.com/twitterapis-vs-getxapi)
-   [TwitterAPIs vs TweetAPI](https://www.twitterapis.com/twitterapis-vs-tweetapi)
-   [TwitterAPIs vs TwexAPI](https://www.twitterapis.com/twitterapis-vs-twexapi)
-   [TwitterAPIs vs RapidAPI](https://www.twitterapis.com/twitterapis-vs-rapidapi)

## Legal

-   [About](https://www.twitterapis.com/about)
-   [Security](https://www.twitterapis.com/security)
-   [Trust](https://www.twitterapis.com/privacy-and-data-handling)
-   [Terms of Service](https://www.twitterapis.com/terms-of-service)
-   [Affiliates](https://www.twitterapis.com/affiliates)
-   [Contact](https://www.twitterapis.com/contact)
-   [Jobs](https://www.twitterapis.com/jobs)

© 2026 TwitterAPIs. All rights reserved.

TwitterAPIs is an independent third-party API for developers and researchers. Not affiliated with, endorsed by, or sponsored by X Corp.

All systems operational