Political Data From Twitter (X): Collect It via API (2026)

By Sorsa Editorial

Updated July 11, 2026: verified the current X API pay-per-use rates and the 2-million-post monthly cap after the April 20 pricing change, and refreshed the collection-cost scenarios against them.

Key Takeaway: Political data on Twitter/X falls into official-account posts, public election discourse, engagement signals, and derived scores. Since the free academic API track closed in 2023, most projects collect their own data through a third-party API: keyword, hashtag, or handle searches, date-bounded pulls, and mention tracking, scoped and rehydrated as needed.

X remains the place where politicians announce, journalists break news, and electorates argue in public, which makes it one of the richest sources of political data anywhere. The hard part is now access. The free academic-research track that powered a decade of political-science papers is gone, the official API is metered and priced for enterprises, and the public datasets researchers relied on are frozen snapshots that no longer rehydrate cleanly.

Sorsa API, an alternative Twitter/X API for public data, is built for this kind of read-heavy collection. It reads public posts, profiles, search results, and engagement through a single API key in a header, with no OAuth handshake and no application queue, at effective rates from $0.02 per 1,000 tweets and from $0.01 per 1,000 profiles. You search by keyword, hashtag, or handle through /search-tweets, bound a collection to an election window with date filters, and track mentions of a candidate through /mentions, all on flat per-request billing that stays predictable whether a dataset is a few thousand posts or a few million.

What counts as political data on X

Political data on X is a loose label covering several distinct datasets that happen to share a platform, and a collection plan has to name which one it is after. Conflating them is the first mistake, because each needs a different query and a different volume budget.

Official-account output is the posts of politicians, parties, government agencies, and candidates: a clean, high-signal record of what official actors said and when. This is a small dataset, often a few thousand posts a month for a whole legislature.

Issue and election discourse is everything the public posts about a candidate, a bill, a hashtag, or an election. It is far larger and far noisier, running to millions of posts around a national vote, and it is the basis of most sentiment and public-opinion work.

Engagement and diffusion is who amplified what, how fast, and how far: reposts, replies, quote-posts, and the timing between them. This is how researchers study influence and the spread of narratives.

Derived signals are sentiment, stance, topic, and bot-likelihood scores computed on top of the raw posts. These are produced by your analysis rather than handed to you, and they are usually the actual research output.

The volume gap between the first and second category is the whole planning problem. A politician-accounts dataset is small and cheap; broad election-discourse collection is where costs and rate limits start to matter.

Where political X data comes from in 2026

There are three real routes to political X data, and serious projects usually combine them: the official X API, frozen public research datasets, and collecting the data yourself through a third-party API.

The official X API is authoritative and complete because it is X's own first-party data. It stopped being the realistic answer for most research budgets in 2023. X ran a dedicated Academic Research track for years, free and generous with full-archive search, and a large share of the published political-science literature was built on it. That track was dismantled, documented in a 2024 study of the API's research contribution that counted more than 27,000 papers built on Twitter data since 2006 before access was cut. New developers now get the same metered, pay-per-use API as everyone else, and research-scale volume runs into an Enterprise contract that has historically started around $42,000 a month.

Public research datasets are the second route: large, peer-reviewed, already collected. Researchers published multi-million-post collections around major elections, such as the Election2020 dataset of over 600 million tweets, along with curated databases of legislators' accounts across many countries. Two limits apply. They are frozen to a fixed window, so they cannot answer anything about what happened after collection ended, and most are distributed as tweet IDs rather than full posts, to comply with platform terms. You get a list of IDs and must rehydrate them by fetching each through an API. Rehydration used to be free and complete; it now runs through a paid API, and every post deleted since the dataset was built comes back empty. Because politically sensitive posts are deleted at a high rate, a years-old election dataset can rehydrate to a fraction of its original size, skewed toward whatever was never taken down.

The third route is to collect the data yourself: pay-per-use, current, and shaped to your exact question, in exchange for building the collection. A common combination uses a public dataset as the historical baseline, your own forward collection for everything after that dataset's window ends, and targeted official-API pulls only where first-party completeness is non-negotiable. For academic groups specifically, Sorsa runs an academic research program with discounted access on top of the standard read-only endpoints.

How much does collecting political Twitter data cost

Collecting political tweets through a flat per-request API costs from $0.02 per 1,000 tweets and from $0.01 per 1,000 profiles, with a full monthly plan from $49. The official X API bills per resource fetched instead, so cost scales directly with dataset size: broad election-discourse collection quickly runs into four figures or hits X's 2-million-post monthly cap, above which only an Enterprise contract applies.

The table maps three common political-collection jobs to each model. Sorsa figures are plan-level; official X API figures use the current per-resource rates from the full 2026 X API pricing breakdown.

One Sorsa request returns up to 100 tweets on the batch endpoints or up to 200 profiles, so a plan's request count stretches much further than a per-post count suggests. That is where the flat model wins on read-heavy political collection: up to 50x cheaper than the official API on the same workload, and no per-resource meter counting toward a cap.

Two per-1,000 figures apply, depending on the endpoint, and it is worth seeing both. Batch endpoints (/tweet-info-bulk and /info-batch, up to 100 items per request) put the effective cost from $0.02 per 1,000 tweets and from $0.01 per 1,000 profiles. Search and timeline endpoints (/search-tweets, /user-tweets, /mentions) return about 20 posts per request, which works out to roughly $0.10 per 1,000 tweets on the Pro plan. Discourse collection uses the search endpoints, so budget against the search figure; profile lookups and known-ID pulls use the batch endpoints and land far lower. Full details sit on the flat per-request pricing page.

Collecting posts from politicians and official accounts

The cleanest political dataset to build yourself is official-account output. You start from a list of handles, a chamber of a legislature, a cabinet, or a slate of candidates, and pull each account's posts through /user-tweets by username, user link, or numeric user ID. The volume is small and steady, well under what discourse collection costs, and it gives a complete first-party record of what those actors posted.

Two practices make this dataset reliable. The first is a curated watchlist rather than a badge filter. After 2022, the blue verified badge became a paid subscription rather than an identity check, so the verified flag on a profile no longer confirms that an account is a genuine official one. The dependable method is to build a handle list from an authoritative source, such as a parliamentary open-data site or an academic legislator database, and validate it once. Real datasets are built this way: a collection of 1.1 million posts from 692 Brazilian federal deputies started from accounts retrieved and manually validated against the Chamber of Deputies open-data website, then labeled by each deputy's election outcome.

The second is stable identifiers. Usernames change; numeric user IDs do not. Resolve each handle to its ID once through /username-to-id/{handle} and store the ID, so a watchlist survives a politician rebranding an account mid-campaign. To refresh the whole watchlist's profile data in one shot, /info-batch accepts up to 100 handles or IDs per request and returns full profiles, which keeps follower counts and bio changes current across a legislature for a handful of requests. When you need a single account's entire back catalogue, the same timeline endpoint pages through it, the approach covered in the guide to pulling a user's full posting history.

Collecting election and issue discourse

Public discourse, what everyone posts and not just officials, is the larger and harder collection. It is a keyword problem: you define a query from candidate names, hashtags, and issue phrases, pin a language, and page through the results. Sorsa's /search-tweets endpoint accepts full Twitter advanced-search syntax, so from:, exact phrases in quotes, hashtags, and Boolean OR all work inside one query, the mechanics detailed in the guide to searching tweets through the API.

Query framing is itself a decision that shapes the dataset before a single post is collected. The hashtags and phrases you choose decide whose conversation you capture: search only one side's hashtag and you have measured one side. The fix is a balanced, documented keyword set covering the full slate. One well-cited example collected 2.2 million tweets around the 2016 US election using a symmetric keyword filter across both major candidates, then used hashtags themselves as the seed for building a labeled training set. To keep a keyword set current during a live campaign, pull the region's trending topics by WOEID through /trends and fold the politically relevant ones into the query, a technique real referendum studies used to catch emerging hashtags as they broke.

For building and testing these queries without writing code first, the visual search query builder composes an advanced-search string in the browser, and the advanced search operator reference lists every operator the endpoint accepts. Scope matters as much as framing: a focused query over a tight window, a single debate night or one bill's news cycle, is often a better dataset than a sprawling one, cheaper to collect and pointed at a sharper question.

Date-bounded pulls and mention tracking

Date bounds turn an open, expensive query into a scoped job. Sorsa handles them two ways. Inside /search-tweets, the advanced-search since: and until: operators go straight into the query string, so a full campaign window collects as one dated pass. For collecting mentions of a specific candidate or account, /mentions exposes native filters in the request body: since_date and until_date in YYYY-MM-DD format, plus min_likes, min_replies, and min_retweets to drop low-engagement noise before it enters the dataset. The workflow itself is covered in the guide to tracking mentions of an account.

The script below collects every post matching a political query inside a date window, paging through results with the response cursor and writing each row to your own storage. Swap the query for a from: chain of official handles and the same loop becomes a politician-account collector.

import requests

BASE = "https://api.sorsa.io/v3"
HEADERS = {"ApiKey": "YOUR_API_KEY"}

# Any political query works here: a hashtag, an issue phrase, a candidate's
# handle with from:, or a Boolean combination. since:/until: bound the
# window, so a debate night or a full campaign collects as one dated job.
query = "(#election OR ballot OR vote) since:2026-10-20 until:2026-11-05 lang:en"

def collect(query, order="latest", max_pages=50):
    rows, cursor = [], None
    for _ in range(max_pages):
        body = {"query": query, "order": order}
        if cursor:
            body["next_cursor"] = cursor
        r = requests.post(f"{BASE}/search-tweets", json=body,
                          headers=HEADERS, timeout=30)
        r.raise_for_status()
        data = r.json()
        for t in data.get("tweets", []):
            rows.append({
                "id": t["id"],
                "created_at": t["created_at"],
                "lang": t["lang"],
                "author": t["user"]["username"],
                "verified": t["user"]["verified"],
                "text": t["full_text"],
                "retweets": t["retweet_count"],
                "likes": t["likes_count"],
            })
        cursor = data.get("next_cursor")
        if not cursor:
            break
    return rows

rows = collect(query)
print(f"collected {len(rows)} posts")
# Persist rows to your own storage. That file is your political dataset.

Real-time mention tracking has one advantage no after-the-fact collection can match: it captures posts before they can be deleted. Politicians delete posts at a high rate, and a deletion is itself a finding, not just missing data. Polling official accounts and candidate mentions forward, on a schedule, turns the deletion problem from silent data loss into a data point you can study. Across the election-window collections we have run, the accounts worth polling most tightly tend to be the ones that delete most, so a tight candidate watchlist and a short poll interval usually go together. Sorsa's flat 20 requests per second on every plan is enough headroom to poll a candidate watchlist through an election night without a per-endpoint rate window resetting mid-collection.

Building a labeled political dataset

Collection gives you raw posts; the research output is almost always a labeled dataset. Assembly is the straightforward part: run the queries above, deduplicate on tweet ID, and store the fields you need, which for most political work means the post text, author handle, timestamp, language, and engagement counts. Each tweet response already carries the full author profile at no extra request, so account-level features like follower count and account age are there without a second call. The full mechanics of turning a raw pull into a training corpus are covered in the guide to assembling a Twitter dataset for machine learning.

Labeling is where the method choices live. Manual annotation by trained coders is the gold standard for stance and sentiment but does not scale past a few thousand posts. A common shortcut in the political-science literature seeds labels from hashtags: a tweet carrying a clearly partisan hashtag is treated as a weak label, and those labels train a classifier that then labels the rest. The 2016 US election dataset above did exactly this, deriving opinion categories from hashtag signals to build a training set of hundreds of thousands of tweets. For sentiment and stance specifically, the walkthrough on classifying tweet sentiment covers collection through classification end to end.

For historical baselines older than a live collection window, the search endpoints reach the full tweet archive back to 2006, so a dataset can pull dated context from past cycles rather than starting at today. The guide to searching old tweets across the full archive covers date-ranged historical pulls in depth.

Pitfalls that wreck a political dataset

Five failure modes quietly ruin political datasets built without them in mind, and they apply no matter which collection route you choose.

X users are not the electorate. The platform's user base skews by age, geography, education, and politics, and it is not the population that votes. Treat X data as a measure of online discourse, not a poll. Forecasts that conflated the two have a poor track record.

Bots and coordinated activity. Political topics attract automated and coordinated posting more than almost any other subject. Raw post counts and raw sentiment are inflated by it, so a bot-likelihood filter is not optional for serious work, and reporting what you filtered is part of the method.

Deleted and edited posts. A dataset collected after the fact silently omits deletions, and deletions of politically sensitive posts run high. Only forward collection captures a post before it can vanish, which is the argument for real-time polling over one-shot historical pulls.

Keyword framing bias. The query is a hypothesis. An unbalanced keyword set produces an unbalanced dataset that no amount of later analysis can fix, so the balanced, documented query from the discourse section is the single most important upstream decision.

Reproducibility. If a dataset was built from an opaque sample, others cannot rebuild it. Document your own collection, the exact query, dates, rate, and endpoint, so your work is reproducible even when your upstream sources were not.

A collection example from practice

A university research group studying a national election needed a full campaign window of public discourse, roughly 3 million posts across six weeks tracking two candidate slates and a set of issue hashtags. On the official X API that volume exceeds the 2-million-post monthly cap, which pushes the project into an Enterprise contract starting historically around $42,000 a month, out of reach for the grant. Moving the same collection to a flat per-request plan brought the data budget under $900 a month, a cut of more than 90 percent, and the group ran the collection forward through election night rather than reconstructing it afterward, so deleted posts were captured before they disappeared. The tradeoff was honest and stated up front: the flat plan is read-only, so any workflow needing writes stayed on the official API, but no part of election-discourse collection needs a write.

FAQ

Can you still collect political data from Twitter for research?

Yes, but the route changed. The free academic-research API track was discontinued in 2023, so most researchers now work from public datasets collected earlier or collect their own through a third-party API that bills per request. The official X API is still authoritative and first-party, but research-scale volume is priced for enterprises rather than individual projects.

How do you collect tweets from a list of politicians?

Start from a curated list of official handles validated against an authoritative source, then pull each account's posts through a user-timeline endpoint by handle or numeric ID. Through a flat-rate API this is cheap because the volume is small, a few thousand posts a month for a whole legislature, and a batch profile endpoint refreshes up to 100 accounts per request.

How much does it cost to collect political tweets?

Through a flat per-request API, collection costs from $0.02 per 1,000 tweets and from $0.01 per 1,000 profiles, inside monthly plans from $49 for 10,000 requests. A politician-accounts dataset is a few dollars a month. Broad election discourse runs to millions of posts, so scope the date range and keyword set to control the bill rather than letting an open query run.

How do you limit a political tweet collection to a specific date range?

Two ways. Inside a keyword search, the advanced-search operators since: and until: go into the query string, so a campaign window collects as one dated pass. For mentions of a specific account, the mentions endpoint takes since_date and until_date fields in YYYY-MM-DD format, plus minimum-engagement filters, so a debate night or a single news cycle collects cleanly without pulling the whole timeline.

Can Twitter data predict election results?

Treat that claim with caution. X users are not a representative sample of the electorate, skewing by age, geography, and politics, so X data measures online discourse rather than vote intention. It is genuinely valuable for studying narratives, agenda-setting, and public reaction to events, and unreliable as a standalone election forecast.

How do you handle bots in political Twitter data?

Assume they are present, because political topics attract automated and coordinated posting more than most subjects. Raw post and sentiment counts are inflated by it, so apply a bot-likelihood filter before analysis and report what you removed. Treating raw volume as genuine public opinion is a common and serious error in political social-media work.

Is it legal to collect political tweets?

Collecting and analyzing public posts for research or journalism is broadly accepted, and public-interest political accounts are squarely public. Follow the API provider's terms, respect deletions and protected accounts, and handle any personal data under the rules that apply to you. Public political speech on a public platform is the least contentious category of social data to study.

Getting started

Political collection is cheap to start and easy to test before committing. Every new account gets 100 free requests: one-time, no credit card, never expiring, and valid across all 40 endpoints, which is enough to run a real politician-accounts pull or a scoped discourse query end to end. That equals up to 10,000 tweets or 20,000 profiles, far more than the small trial credits typical of pay-per-use providers.

Try a query in the browser first through the API playground, then wire the same call into a script with a single ApiKey header. When a collection grows past a scoped test, flat plans scale from 10,000 to 500,000 requests a month at a fixed price, so an election-cycle project has a predictable data budget from the start.

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

This guide draws on hands-on operation of the Sorsa API's search, timeline, and mention endpoints, the current X API pay-per-use pricing verified against X's developer console rates as of July 11, 2026, and the political-science literature on Twitter data collection, including the API research-contribution study (arXiv 2404.07340), the Election2020 dataset (arXiv 2010.00600), the Brazilian legislators dataset (arXiv 1805.01589), and the 2016 US election opinion study (arXiv 2002.00854). Two collection models were compared: the official X API and Sorsa's flat per-request API.