Historical Twitter Data: Get Old Tweets via API (2026)

By Sorsa Editorial

Updated July 2026: added the 100 free requests starting option, restated pricing per 1,000 tweets and 1,000 profiles, and re-confirmed the full-archive March 2006 start and the 3,200-tweet timeline cap.

The official path narrowed sharply over the last three years. X closed its free Academic Research track to new applicants in 2023, dropped fixed-tier plans for new developers in early 2026, and now bills per resource read, which makes large historical pulls expensive. Sorsa API, an alternative Twitter/X API, takes a different shape. Its /search-tweets endpoint runs full-archive keyword search back to 2006 with the standard since: and until: operators, returns the complete tweet object with the author profile in a single call, and bills a flat rate per request instead of per tweet read. Pricing starts at $0.02 per 1,000 tweets and $0.01 per 1,000 profiles on the batch endpoints, at a flat 20 requests per second on every plan with no developer-account approval. New accounts also get 100 free requests to test the archive first: one-time, no card, and they never expire.

We build and run this API and rebuild historical pipelines off the official endpoints regularly, so the tradeoffs here come from doing the work, not from summarizing documentation.

Historical Twitter data at a glance

Five methods cover almost every real use case. They differ on archive depth, cost, setup effort, and how much data you can realistically pull.

Why is historical Twitter data harder to get in 2026?

Historical Twitter data is harder to get in 2026 because there is no public complete archive to download and the cheap programmatic routes that researchers relied on have closed. The full back catalog of public tweets exists, going back to March 2006, but you reach it only through search or paid access, and the affordable options shrank between 2023 and 2026.

Three platform shifts reshaped access. In February 2023, the free API tier became a write-only stub and paid tiers replaced it. In mid-2023, the Academic Research track that powered most published Twitter research stopped accepting new applicants. In early 2026, X moved new developers onto pay-per-use credits, where reads cost roughly $0.005 per resource and pay-per-use accounts are capped at two million reads a month. The legacy Pro tier at $5,000 a month still bundles full-archive search but is closed to new signups. For the full tier-by-tier picture, see our 2026 Twitter API pricing breakdown.

There is also no institutional shortcut. The Library of Congress once agreed to preserve every public tweet, taking Twitter's full back catalog from 2006 onward, but it stopped comprehensive archiving at the end of 2017 and now collects only selectively, and that 2006 to 2017 collection stays embargoed from public access. No outside body holds a queryable copy of the archive. That is why third-party data APIs and open-source scrapers absorbed most of the displaced volume.

The five methods in detail

X Advanced Search

X Advanced Search is the free, manual route, and it reaches back to 2006 directly in the web interface. It supports since: and until: operators and is useful for finding a known tweet or sampling a small window. It does not export, returns no structured data, and is unworkable at any scale, because results are paginated and you scroll them by hand. Old date ranges also surface noisy results, since the relevance ranking deprioritizes old content.

Official X API full-archive search

The official search/all endpoint offers the same archive depth as a third-party API but with three frictions in 2026. New developers must use pay-per-use credits with no fixed monthly cost. The v2 response returns minimal fields by default, so you must explicitly request the engagement metrics, author profile, and media you need. And the two-million-read monthly cap on pay-per-use is a hard ceiling that real research budgets hit quickly. Authentication is OAuth 2.0 with a bearer token, which adds its own setup overhead before the first archive query runs.

Open-source scrapers

Open-source scrapers reach old tweets by reverse-engineering X's web endpoints, which makes them free and fragile. The well-known names, snscrape and twint, are effectively dead, with snscrape untouched for years and twint archived. A few maintained libraries remain, but they share the same failure mode: a working scraper breaks the moment X rotates its frontend tokens, with no migration path. For the current state of these tools, see our breakdown of which Twitter scrapers still work in 2026.

Academic datasets

Pre-built archives ship tweet IDs rather than full tweets for specific events. You rehydrate the IDs against an API to retrieve the current content, which means every year that passes since a dataset was built, more tweets have been deleted, suspended, or made private and drop out. Repositories such as TweetSets from George Washington University and the DocNow catalog cover major events, and the Wharton research database offers a roughly 1% sample of all tweets queryable by SQL. Hydration still requires API access, which loops back to the pricing question; for teams that lost the Academic Research track, our academic research access covers the same date-windowed queries on free or discounted plans.

Third-party data API

A third-party data API is the most reliable route for programmatic access: a single key, structured JSON, and pagination over the full archive. Sorsa is one such alternative Twitter/X API. Its /search-tweets endpoint covers the archive from March 2006, returns every field by default including the author profile embedded in each tweet, and charges a flat rate per request rather than per tweet read. That flat model is the main reason a large backfill that runs into thousands of dollars on the official API lands in the low hundreds here.

What "full archive" actually means (and what you cannot get)

"Full archive" is the most overused phrase in this space. Every provider claims it, and none of them, including the official API itself, can return four categories of data. These are platform-level limits, not gaps in any one tool, and they apply equally to the official X API, Sorsa API, and every other provider.

Deleted tweets. Once a tweet is deleted, it leaves X's search index and no API can recover it. The Wayback Machine occasionally holds a screenshot of a high-traffic profile page, but that is an image, not the tweet.

Tweets from protected accounts. Accounts with protected posts are excluded from public search and timeline endpoints. The only way to read those tweets is to be an approved, authenticated follower.

Historical profile snapshots. Profile data reflects the current state. A tweet from 2014 returned today shows the author's 2026 username and bio, not what they had in 2014. If the handle changed three times since, you see the current one.

Historical engagement snapshots. This is the one that trips up sentiment and influence research. A tweet from 2018 retrieved today shows its current like count, not the count it had in 2018. There is no time-machine endpoint anywhere in the X ecosystem. If you need point-in-time engagement, ingest tweets as they post and store the metrics yourself. The patterns for that are in the real-time monitoring docs.

How to search historical tweets with the API

Two endpoints cover historical work, depending on whether you search by keyword across users or pull one account's full timeline.

Authentication is a single ApiKey header. Every response is flat JSON with the full tweet object, including the embedded author profile, media entities, and engagement metrics. A minimal request:

curl -X POST https://api.sorsa.io/v3/search-tweets \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "\"climate change\" since:2015-06-01 until:2015-12-31 lang:en min_faves:10",
    "order": "latest"
  }'

That returns English tweets matching the phrase "climate change" between June and December 2015 with at least 10 likes, sorted chronologically. The full operator set (from:, to:, filter:, min_retweets:, exact phrases, Boolean logic) lives in our Twitter search operators reference, which covers the syntax you need to narrow any archive query.

Search a date range with pagination (Python)

The most common historical workflow is event analysis: pull every English tweet matching a topic in a defined window. Loop on next_cursor until it comes back empty.

import requests
import time

API_KEY = "YOUR_API_KEY"
URL = "https://api.sorsa.io/v3/search-tweets"

def search_historical(query, max_pages=50):
    """Search the full tweet archive with automatic pagination."""
    all_tweets = []
    next_cursor = None

    for page in range(max_pages):
        body = {"query": query, "order": "latest"}
        if next_cursor:
            body["next_cursor"] = next_cursor

        resp = requests.post(
            URL,
            headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
            json=body,
        )
        resp.raise_for_status()
        data = resp.json()

        tweets = data.get("tweets", [])
        all_tweets.extend(tweets)
        print(f"Page {page + 1}: {len(tweets)} tweets (total: {len(all_tweets)})")

        next_cursor = data.get("next_cursor")
        if not next_cursor:
            break
        time.sleep(0.1)

    return all_tweets


tweets = search_historical("SpaceX since:2015-06-01 until:2015-07-01 lang:en")

Each tweet object includes the full text with no 140-character truncation, the language code, the conversation ID for thread reconstruction, all six engagement counts, media entity URLs, and the complete author profile. You never need a second call to fetch the user. For more Python patterns, including retries and quirks at scale, see our Twitter API in Python guide.

Surface high-engagement historical content (JavaScript)

For content research, sort by popularity rather than chronology. Combine order: "popular" with min_retweets: and -filter:nativeretweets to surface the original tweets that actually moved in a given period instead of a flood of retweets.

const API_KEY = "YOUR_API_KEY";
const URL = "https://api.sorsa.io/v3/search-tweets";

async function searchHistorical(query, maxPages = 10) {
  const allTweets = [];
  let nextCursor = null;

  for (let page = 0; page < maxPages; page++) {
    const body = { query, order: "popular" };
    if (nextCursor) body.next_cursor = nextCursor;

    const resp = await fetch(URL, {
      method: "POST",
      headers: { "ApiKey": API_KEY, "Content-Type": "application/json" },
      body: JSON.stringify(body),
    });
    if (!resp.ok) throw new Error(`API error: ${resp.status}`);

    const data = await resp.json();
    const tweets = data.tweets || [];
    allTweets.push(...tweets);

    nextCursor = data.next_cursor;
    if (!nextCursor) break;
    await new Promise((r) => setTimeout(r, 100));
  }

  return allTweets;
}

// Viral Tesla tweets from 2019, originals only
searchHistorical(
  'Tesla since:2019-01-01 until:2019-12-31 min_retweets:1000 -filter:nativeretweets lang:en'
).then((t) => console.log(`Collected ${t.length} tweets`));

The -filter:nativeretweets flag matters here. Without it, popular searches return the same viral tweet dozens of times as retweets and bury the original underneath.

Export to CSV and Pandas

A production pipeline collects tweets, writes them to CSV, then loads them for analysis. The same response structure drops straight into a DataFrame:

import pandas as pd

def to_dataframe(tweets):
    rows = []
    for t in tweets:
        u = t.get("user", {})
        rows.append({
            "created_at": pd.to_datetime(t["created_at"]),
            "username": u.get("username"),
            "followers": u.get("followers_count", 0),
            "text": t["full_text"],
            "likes": t.get("likes_count", 0),
            "retweets": t.get("retweet_count", 0),
            "views": t.get("view_count", 0),
            "lang": t.get("lang"),
        })
    return pd.DataFrame(rows)

df = to_dataframe(tweets)
df.to_csv("historical_tweets.csv", index=False)

From there you have a clean frame for engagement-rate series, sentiment scoring, or regression. For a full sentiment workflow, see our companion guide on Twitter sentiment analysis, and for assembling a labeled corpus, building a Twitter dataset for machine learning.

Strategies for large-scale historical collection

A few patterns hold up for any backfill above a few thousand tweets.

Chunk large date ranges into monthly windows. A single query over a full year gives you no control over batch size and no clean resume point if a request fails halfway. Splitting by month lets you parallelize, retry, and audit cleanly, and you break further into weekly or daily chunks for volatile windows like an election or a market crash.

Filter retweet noise. Historical popular searches return a flood of retweets. Add -filter:nativeretweets when you want original content, or -filter:retweets to also drop legacy "RT @user" style reposts.

Pair engagement filters with date ranges. Combining since: and until: with min_faves: or min_retweets: surfaces only tweets that gained traction in your window, which cuts both noise and request volume. For tips on trimming unnecessary calls and handling the cursor mechanics cleanly, see optimizing API usage.

Backfill once, then monitor forward. Engagement counts are current totals, not point-in-time snapshots, so for ongoing research the strongest pattern is to backfill the historical window once and attach a real-time monitor going forward. That gives you both the historical baseline and accurate point-in-time metrics for everything new.

Scraping a full account timeline

If your goal is one account's complete posting history rather than a keyword search across users, use /user-tweets instead. It walks the timeline newest to oldest until the cursor is empty, with no equivalent of the 3,200-tweet cap that limits the official API's timeline endpoint.

import requests

resp = requests.post(
    "https://api.sorsa.io/v3/user-tweets",
    headers={"ApiKey": "YOUR_API_KEY", "Content-Type": "application/json"},
    json={"username": "naval"},
)

That is a different workflow from archive search, with its own cost math and a comparison against GUI tools and scrapers. Our dedicated guide on downloading all tweets from a user covers it end to end. The rest of this article stays on cross-user historical search.

In practice: rebuilding history off the official API

The teams who feel the 2026 squeeze most are the ones backfilling years of data on a budget. A quantitative fund we worked with wanted a sentiment-momentum signal from crypto tweets, backtested against five years of price action. Step one was a backfill of every tweet from a curated list of about 400 accounts plus English tweets matching 30 keywords from 2019 to 2024. On the official tiers the read cap was the binding constraint, and the projected bill ran well into five figures. Rebuilt against a flat-rate archive API, the same backfill finished in three days of pagination for a few hundred dollars, and the strategy has run live since.

A different shape, same lesson: an academic group running a longitudinal discourse study had built its whole methodology around the Academic Research track. When the track closed to new applicants, the replacement ran the same from: and keyword queries against a flat plan and re-validated results against the smaller dataset collected during the original access. The rebuild cost a single Starter month. In both cases the blocker was access economics, not the data itself, and a flat per-request model removed it.

Frequently asked questions

How far back does Twitter/X archive search go?

To March 21, 2006, the date of the first public tweet. Both the official X API's full-archive search and Sorsa API's /search-tweets endpoint cover the complete public archive from that date forward. Tweets that have since been deleted or made private by their authors are excluded from any result, because they no longer exist in the platform's search index.

Can you get deleted tweets through any API?

No. Once a tweet is deleted, it is removed from X's search index and no public API can retrieve it. Your only options are external captures made before deletion, such as Wayback Machine screenshots or a monitoring service that ingested the tweet in real time. If preserving deletable content matters, ingest tweets as they post and store them on your own side.

Is the Twitter Academic Research API still free?

Not for new applicants. X stopped accepting new applications to the Academic Research track in 2023. Researchers who had access before that retain it for now, but no new academic seats are issued. Most academic projects in 2026 either use a remaining seat, work from pre-built datasets, or migrate to a flat-rate third-party archive API to run the same date-windowed queries.

How much does it cost to search the full archive in 2026?

On the official X API's pay-per-use model, reads run around $0.005 each with a two-million-read monthly cap, and the legacy Pro tier that bundled full-archive search at $5,000 a month is closed to new signups. Sorsa API uses flat monthly plans instead: $49 for 10,000 requests, $199 for 100,000, and $899 for 500,000, with each search request returning up to 20 tweets.

Can you retrieve a tweet's engagement metrics from a specific past date?

No. Engagement counts on any returned tweet, the likes, retweets, replies, views, quotes, and bookmarks, reflect current totals, not the totals on a specific past date. The platform stores no historical snapshots of engagement. If you need point-in-time metrics, you have to ingest the tweet in real time and record the numbers yourself at that moment.

How do you search tweets between two specific dates?

Use the since:YYYY-MM-DD and until:YYYY-MM-DD operators in your query. since is inclusive of the start date and until is exclusive of the end date, so since:2020-01-01 until:2020-02-01 returns the full month of January 2020. Combine them with lang:, min_faves:, and -filter:retweets for cleaner results across the archive.

Is there an affordable API for historical Twitter data without per-tweet billing?

Yes. Sorsa API charges a flat rate per request rather than per tweet read, so a search returning 20 tweets costs the same whether those tweets are from 2024 or 2009. At $199 a month for 100,000 requests on the Pro plan, that is roughly two million tweets, so a large historical backfill costs a few dollars instead of the thousands a per-resource model bills.

Getting started

To test archive search before writing code, the Sorsa API Playground fires requests against /search-tweets and /user-tweets from the browser with no key required, and the visual query builder lets you assemble operators by hand. When you are ready to integrate, grab a key from the dashboard and follow the quickstart: no approval, no OAuth, a single API key, and a flat 20 requests per second on every plan. Every new account starts with 100 free requests, one-time and with no card, that never expire and cover all 40 endpoints, which is enough to validate a date-windowed query before committing. The Starter plan at $49 for 10,000 requests covers most one-off backfills, including event analysis or a single-topic study over a year window.

Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.

This guide draws on our own work running an alternative Twitter/X API since 2022 and rebuilding historical pipelines off the official endpoints. We verified the full-archive March 2006 start and the limits of comprehensive collection against the Library of Congress account of its Twitter archive, re-checked the official X API pay-per-use rates against X's published developer pricing, and took endpoint behavior, operators, and per-request costs from the Sorsa API documentation and our published 2026 pricing breakdown. We compared five access methods for this piece. More about the team is on our about page. Last verified July 4, 2026.