TwitterAPIs vs Tweepy

One Job, Two Setups

Below is the identical task, fetching a user's latest tweets, written once in Tweepy and once in TwitterAPIs. The Tweepy version needs an X API bearer token tied to a developer account. The TwitterAPIs version needs a single Bearer token and no X account at all.

import tweepy

# Requires an X API bearer token from a developer account.
# Reads count against your X API tier rate limits.
client = tweepy.Client(bearer_token="YOUR_X_API_BEARER_TOKEN")

user = client.get_user(username="elonmusk")
tweets = client.get_users_tweets(user.data.id, max_results=10)

for tweet in tweets.data:
    print(tweet.text)

Where Tweepy Wins

Tweepy is a seasoned, free, idiomatic Python SDK. When the X API access it depends on is already in hand, it is a clean way to put that access to work. Reach for Tweepy when you:

TwitterAPIs Pricing, Spelled Out

Tweepy in 2026: Status and What Changed Under It

Tweepy itself is fine. It is still an actively maintained open-source Python library, it still has the cleanest object model of any X client, and nothing in this comparison is a criticism of the code. What changed is the thing underneath it. Tweepy is a wrapper, and a wrapper can only reach the endpoints the platform still serves you on the tier you are paying for.

That is why so much older Tweepy code stops working without a single line being edited. The v1.1 standard search that most tutorials were written against is gone from the tiers most people are on, so API.search_tweets raises rather than returns. The v2 replacements exist, but recent-search and the higher-volume read endpoints sit behind paid access, and the free tier is scoped around posting rather than reading at any useful volume. Upgrading Tweepy does not fix any of that, because the library was never the constraint.

Worth knowing before you price a fix: the $200 Basic tier that most older write-ups quote is gone. X moved self-serve access to consumption billing in February 2026 and migrated the remaining Basic subscribers onto it from 1 June 2026, so reads now bill from $0.005 a resource rather than out of a monthly allowance. An estimate built against Basic is out of date in both directions.

The practical read for 2026: if you already hold X API access at a tier that covers your reads, Tweepy is still the right tool and you should keep it. If your project stalled at the credentials step, or an old collector broke and the cost of restoring it is now a per-resource meter, the library is not what you need to replace.

What the Migration Buys You, In Practical Terms

Moving reads off Tweepy is not a rewrite. It is deleting one dependency and swapping typed SDK calls for HTTP requests. Here is what actually changes on the day you do it.

Building a Production Data Collector: Pagination, Retries, and pandas

A single request is the easy part of either stack. What a real collector needs is a page loop, a retry that backs off instead of hammering, and something that lands the rows in a shape you can analyse. Tweepy gives you tweepy.Paginator and wait_on_rate_limit for the first two. Over REST you write them once, in about twenty lines, and then they are the same across every endpoint.

import time
import pandas as pd
import requests

BASE = "https://api.twitterapis.com/twitter/user/tweets"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}


def fetch_page(username, cursor=None, attempt=1):
    params = {"userName": username}
    if cursor:
        params["cursor"] = cursor
    r = requests.get(BASE, params=params, headers=HEADERS, timeout=30)
    # 429 and 5xx are the only two worth retrying. A 4xx is a bug in the
    # request, so raise it now instead of sleeping on it five times.
    if r.status_code in (429, 500, 502, 503, 504) and attempt <= 5:
        time.sleep(2 ** attempt)
        return fetch_page(username, cursor, attempt + 1)
    r.raise_for_status()
    return r.json()


def collect(username, max_pages=50):
    rows, cursor = [], None
    for _ in range(max_pages):
        page = fetch_page(username, cursor)
        rows.extend(page.get("tweets", []))
        cursor = page.get("next_cursor")
        if not page.get("has_more") or not cursor:
            break
    return pd.DataFrame(rows)


df = collect("elonmusk")
print(len(df), "tweets")
print(df[["created_at", "text"]].head())

Both versions land in the same DataFrame. The difference is what happens when the volume goes up. The Tweepy loop is correct and will still be sleeping through rate windows on the tier you bought, so throughput is capped by the plan rather than by your code. The REST loop has one ceiling, 600 requests per minute, and 1,000 tweets costs $0.04 whether you pull them in one minute or over a week.

In Practice: Moving Read-Only Pulls Off the Official API

The migration most teams actually run is not all-or-nothing, and framing it as a choice between two products is the part this page would get wrong if we left it there. Reads and writes have different constraints, so split them.

Writes that act as your own account, posting, replying, liking, following, are exactly what OAuth user context is for, and Tweepy against the official API is a reasonable way to do them. Reads are the part where the paywall and the rate windows bite, and reads are also the part with no account identity attached, so nothing is lost by sourcing them elsewhere. That gives you a clean split:

If you go all the way and drop the official API entirely, note what that costs you: writes then act as a linked X account rather than through X's own OAuth screen, which is a different trust model and worth a decision rather than a default. For read-only analytics, research, and monitoring workloads, which is most of what Tweepy gets used for, that question never comes up.

More Comparisons