Twitter Analytics API: How to Pull Tweet Metrics 2026

By Sorsa Editorial

Updated June 2026: corrected how X's native dashboard is gated (account-level analytics is Premium-only on desktop, while per-post stats stay free), added a full reference for the X API v2 public_metrics object, and refreshed the official X API pay-per-use rates.

If you have searched for "twitter analytics API," you have already hit the catch: the phrase covers at least three different systems, and the one most people actually want, programmatic engagement data for accounts they do not own, is the hardest to get cheaply through official channels. That is the gap Sorsa API, an alternative Twitter/X API, was built to close. A single request to its /user-tweets endpoint returns up to 20 tweets with full engagement metrics and the author's complete profile, on a flat 20 requests per second across every plan and a setup that takes minutes with no app approval. On the Pro plan that works out to roughly $0.0001 per tweet, against $0.005 per post on the official X API.

We build and run that API and test these workflows against the live official endpoints, so the comparisons below use real current numbers rather than rounded marketing claims. Here is what each option gives you, where it breaks, and how to pull the data yourself.

Contents:

• What people mean by a Twitter analytics API
• Which tweet metrics you can pull through an API
• Inside the X API v2 public_metrics object
• How to pull tweet analytics with Python
• How to calculate engagement rate from API data
• What you can analyze beyond raw counts
• In practice: competitive monitoring on a flat budget
• What happened to academic research access
• Frequently asked questions
• Getting started

What people mean by a Twitter analytics API

"Twitter analytics API" refers to three separate systems that are easy to confuse: X's built-in analytics dashboard (visual, account-level, Premium-gated), the official X API v2 (REST endpoints that return raw metric fields), and the X Ads API (campaign metrics for advertisers). They serve different audiences, return different data, and have different access rules. Picking the wrong one is the most common reason a project stalls.

X's native analytics dashboard

The dashboard inside X (reachable through Creator Studio, or at x.com/i/account_analytics) shows a 28-day account overview: impressions, profile visits, follower changes, and engagement rate, plus per-post breakdowns. There is no API, no export, and no automation behind it.

Access changed in 2024. The full account-level dashboard on desktop now requires an X Premium subscription, while per-post stats remain free for everyone and are still viewable on each post and through the mobile app. So a free account is not locked out of analytics entirely, as some guides claim, but it cannot reach the account-level overview without Premium, and nothing in the dashboard is programmatically accessible. For anything automated, you need one of the two API options below.

The official X API v2

The official X API v2 returns tweet and user data through REST endpoints, and for analytics there are two relevant categories of metric.

public_metrics is available for any public post with an app-only Bearer token: likes, retweets, replies, quotes, impressions (labeled impression_count), and bookmarks. This is what most developers actually need.

organic_metrics and non_public_metrics are restricted to posts authored by the authenticated account and require OAuth 2.0 user-context authentication. They add the owner-only breakdown: profile clicks, URL link clicks, and detailed media-view counts. The X API runs on pay-per-use pricing, where reading a post costs $0.005 per resource and reading a user profile costs $0.010 per resource, with no free tier and credits bought upfront.

One point worth clearing up, because it appears in a lot of AI-generated answers: the "post analytics endpoint" with a 90-day range and 15-plus metrics is part of the X Ads API, specifically its asynchronous analytics jobs for promoted content, not a general organic-post endpoint. For organic engagement on arbitrary public posts, public_metrics is the field you use.

The X Ads API

The X Ads API is a separate system for advertisers. It tracks campaign-level metrics such as promoted impressions, CPM, click-through rate, conversions, and audience segmentation, and it offers synchronous calls for real-time optimization plus asynchronous jobs that return downloadable reports across longer date ranges. If you are not running paid campaigns on X, it is irrelevant. The rest of this guide covers getting public tweet and user metrics through code.

Which tweet metrics you can pull through an API

Through an API you can pull every public engagement metric on a post, likes, retweets, replies, quotes, impressions (views), and bookmarks, for any public account. Owner-only metrics like profile clicks, link clicks, and detailed video retention are available only to the authenticated account holder. No public API returns a historical follower-count graph; you build that yourself from periodic snapshots.

Here is what each source actually exposes:

Two things stand out. The X API v2 public_metrics fields are genuinely useful: with a Bearer token you can read core engagement metrics for any public post. The cost and structure are the limitation. At $0.005 per post read, metrics for 10,000 tweets cost $50, and each tweet is a separate resource charge, with author profiles billed again as user reads on top.

A flat-rate alternative changes that math. An alternative Twitter/X API returns all of these public metrics for any public post and includes the full author profile (followers, following, tweet count, bio, verified status) in the same response at no extra charge. One request returns 20 tweets with complete engagement data plus author context, instead of separate calls for tweets and users. The honest tradeoff is that a public-data API cannot give you the owner-only organic_metrics breakdown (profile clicks, link clicks), and it is read-only, so it covers analysis, not posting. For teams reading engagement at volume rather than auditing their own paid campaigns, that tradeoff favors the flat-rate route, which is why most data pipelines that migrate off the official API for analytics land there.

Inside the X API v2 public_metrics object

The X API v2 public_metrics object holds six public engagement totals for a post: like_count, retweet_count, reply_count, quote_count, impression_count (views), and bookmark_count. The API returns only a post's id and text by default, so you must request the object explicitly with the tweet.fields=public_metrics query parameter, or it will not appear in the response.

The six fields, in plain terms:

• like_count: total likes on the post.
• retweet_count: direct retweets, not counting quote tweets.
• reply_count: total replies in the thread.
• quote_count: times the post was quote-tweeted.
• impression_count: total views, the same number X labels "views" in the UI.
• bookmark_count: times the post was bookmarked.

Two behaviors trip up most developers. First, if the ID you query belongs to a retweet rather than an original post, the values inside public_metrics come back mostly as 0. To read the underlying post's real numbers, request it with expansions=referenced_tweets.id and read the metrics off the referenced original. Second, API metrics lag the on-screen counts: a like or retweet can take minutes to a few hours to register in the API response, so treat the numbers as near-real-time rather than instantaneous.

It is also worth knowing that the separate v2 analytics surface reports organic metrics only; promoted (paid) totals for a post still arrive through public_metrics on a standard post lookup, not through the analytics product.

The same six metrics come back from the Sorsa response format as likes_count, retweet_count, reply_count, quote_count, view_count, and bookmark_count on every tweet object, with the retweet and quote nesting already resolved. You read a quoted post's real numbers off the nested object directly, without chaining an expansions parameter.

How to pull tweet analytics with Python

To pull tweet analytics in Python, send an authenticated HTTP request to a metrics endpoint and read the engagement fields off the JSON response. With the official X API v2 you request tweet.fields=public_metrics for a single post; with a flat-rate REST API you can fetch a whole timeline of tweets, each carrying metrics and author data, in one call.

Option 1: official X API v2

To get public metrics for a specific tweet, make an authenticated GET request with the public_metrics field:

import os
import requests

bearer_token = os.environ["X_BEARER_TOKEN"]
tweet_id = "1882368585664626774"

url = f"https://api.x.com/2/tweets/{tweet_id}"
params = {"tweet.fields": "public_metrics,created_at"}
headers = {"Authorization": f"Bearer {bearer_token}"}

response = requests.get(url, headers=headers, params=params)

if response.status_code == 200:
    metrics = response.json()["data"]["public_metrics"]
    print(f"Likes:     {metrics['like_count']}")
    print(f"Retweets:  {metrics['retweet_count']}")
    print(f"Replies:   {metrics['reply_count']}")
    print(f"Views:     {metrics['impression_count']}")
    print(f"Bookmarks: {metrics['bookmark_count']}")
else:
    print(f"Error: {response.status_code} - {response.text}")

This works per post. Authentication is a Bearer token for public_metrics on any post, or OAuth 2.0 user context for organic_metrics on your own posts. The cost is $0.005 per post read, and pulling a user's last 100 tweets means several paginated requests, each charged per resource returned.

Option 2: a flat-rate REST API

With a single call to a timeline endpoint, you get up to 20 tweets with all engagement metrics and the author's full profile. The Sorsa quickstart covers setup; the request itself is one POST:

import requests

api_key = "YOUR_SORSA_API_KEY"
url = "https://api.sorsa.io/v3/user-tweets"

payload = {"username": "elonmusk"}
headers = {"ApiKey": api_key}

response = requests.post(url, json=payload, headers=headers)

if response.status_code == 200:
    for tweet in response.json()["tweets"]:
        interactions = (
            tweet["likes_count"]
            + tweet["retweet_count"]
            + tweet["reply_count"]
            + tweet["quote_count"]
        )
        views = tweet["view_count"]
        rate = (interactions / views * 100) if views else 0
        print(f"{tweet['full_text'][:50]}... "
              f"views={views:,} rate={rate:.2f}%")
else:
    print(f"Error: {response.status_code}")

The cost is $0.00199 per request on the Pro plan, so 20 tweets with full metrics land at roughly $0.0001 per tweet, and the author profile inside each tweet object costs nothing extra. When you already hold a list of tweet IDs, the /tweet-info-bulk endpoint accepts up to 100 IDs in one request, which is far cheaper than looping single-post lookups on either API.

How to calculate engagement rate from API data

Engagement rate from API data is the sum of public interactions divided by impressions, times 100: (likes + retweets + replies + quotes) / views x 100. For an account above roughly 50,000 followers, a rate over about 0.2% on this impressions-based formula is generally considered healthy. The figure runs lower than X's native dashboard, which also counts profile clicks, link clicks, and media expansions in the numerator.

A reusable function that works on batch tweet data:

def engagement_rate(tweet: dict) -> float:
    interactions = (
        tweet.get("likes_count", 0)
        + tweet.get("retweet_count", 0)
        + tweet.get("reply_count", 0)
        + tweet.get("quote_count", 0)
    )
    views = tweet.get("view_count", 0)
    if not views:
        return 0.0
    return round(interactions / views * 100, 4)

A worked example: a post with 891 likes, 142 retweets, 38 replies, 23 quotes, and 284,500 views has a rate of (891 + 142 + 38 + 23) / 284,500 x 100 = 0.38%. The formula uses only public metrics, so the numbers stay consistent and comparable across accounts even though they read lower than the dashboard's blended figure.

This section is the metrics-and-rate reference. If what you need is the people and text behind those counts, the actual replies, quote tweets, and retweeter profiles, that is a different job covered in the Twitter engagement API guide. For a quick check without writing code, the free engagement calculator computes the rate across an account's recent tweets.

What you can analyze beyond raw counts

Beyond per-post counts, API data supports the analytics dimensions a dashboard shows: follower growth over time, follower-to-following ratio, audience location and language, best-time-to-post patterns, hashtag and topic performance, share of voice against competitors, and identifying your highest-value followers. Each is built by collecting the right endpoint on a schedule and aggregating in your own code, because the analytics layer lives in your stack, not in the API.

How the common dimensions map to real data:

• Follower growth. No API returns a historical follower graph, so you snapshot a profile through /info on a schedule and store followers_count. Daily snapshots are enough for most reporting.
• Audience geography and language. Follower distribution by country is a standard input for targeting and is covered in detail in the guide to analyzing followers by country.
• Competitor benchmarking and share of voice. Pull each rival's timeline and compute volume and average engagement; the workflow is laid out in competitor analysis.
• Sentiment and topic analysis. Classifying the opinion behind mentions is its own pipeline (extraction, cleaning, scoring), walked through in Twitter sentiment analysis rather than duplicated here.
• Highest-value followers. For crypto and Web3 audiences specifically, Sorsa Score ranks an account's followers by influence so you can see who actually matters in its audience.
• Brand mentions with reach filters. The /mentions endpoint supports min_likes, min_retweets, and date bounds, so you analyze mentions that have real reach instead of zero-engagement noise.

The visualization sits on top. A common stack is to pull tweets with requests, load them into a pandas DataFrame, compute rates and rolling averages, and chart trends with matplotlib. The API hands you clean JSON; the dimensions above are what you derive from it.

In practice: competitive monitoring on a flat budget

A pattern we see often: a mid-size direct-to-consumer marketing agency needed to track about 15 competitor accounts for a client, weekly tweet volume, engagement rates, and brand-mention reach. Their previous setup ran on the old X API Pro tier at $5,000 per month, and after X moved to pay-per-use, costs became hard to forecast because every resource fetch was billed individually.

We restructured the pipeline around three calls. A weekly job hits /user-tweets for each competitor and collects the last 20 tweets with metrics, which is 15 requests per week. Brand mentions come from /mentions filtered by min_likes and a since_date, so the report only surfaces mentions with reach. A monthly /info snapshot per account tracks follower deltas over time.

Total volume sits around 7,000 requests per month, comfortably inside the Starter plan at $49. The cost drop is real, not a one-off: Sorsa is roughly 30 to 50 times cheaper than the official per-resource pricing for this kind of read-heavy work, which is grounded in the published rates, not a promise. The data also came out more granular than their old reports, since quote counts and bookmark counts ship in every tweet object. The same three-endpoint shape underpins most agency reporting tools; the analytics logic, anomaly flags, and trend detection live in code on top of the JSON. Costs scale predictably, and the same pipeline scales into a full competitor tracking setup.

What happened to academic research access

X discontinued free Academic Research API access for new applicants in 2023. Researchers who held it before then keep their access, but no new academic accounts are being issued. The only remaining special path is for EU-affiliated researchers studying systemic risks under the Digital Services Act (Article 40), and approvals there are narrow. Everyone else uses the paid pay-per-use tiers or a third-party API.

If your research only needs public tweet metrics and engagement data, not private user information or firehose streaming, a third-party REST API is the practical route. You get structured JSON with the same public metrics, no months-long approval, and full coverage of historical tweet data back to 2006, and research teams can apply for discounted academic research access. The metrics returned reflect the present state of each post, which is the standard behavior for retroactive metric collection on any API.

Frequently asked questions

Can you get analytics for someone else's tweets?

Yes, but only public metrics. The X API v2 public_metrics field (likes, retweets, replies, quotes, views, bookmarks) is available for any public tweet with a Bearer token. The owner-only organic_metrics breakdown, which adds profile and link clicks, is restricted to posts authored by the authenticated account. Third-party APIs like Sorsa return the same public metrics for any public post or account.

Is the Twitter analytics dashboard free?

Partly. Since 2024, X's full account-level analytics dashboard on desktop requires an X Premium subscription. Per-post stats stay free for all users and remain viewable on each post and through the mobile app. So a free account can still see how individual posts perform, but cannot reach the 28-day account overview without Premium, and none of the dashboard is accessible programmatically.

How much does the X API charge to read tweet metrics?

The X API uses pay-per-use pricing with no free tier. Reading a post costs $0.005 per resource and reading a user profile costs $0.010 per resource. You buy credits upfront and they are deducted per call, with no monthly subscription. Pulling 10,000 tweets with their authors costs about $150, since each tweet and each author profile is billed separately.

What is the difference between views and impressions on X?

For public tweet data, "views" and "impressions" are the same number: how many times a post appeared on a screen. The X API v2 labels this field impression_count inside public_metrics, while Sorsa API labels it view_count. In the X Ads API, "impressions" instead refers specifically to paid ad delivery, which is a separate metric, so the two should not be conflated.

What is an affordable way to pull X engagement data at scale in 2026?

Most teams use a flat-rate third-party API. Sorsa API charges one request per call regardless of endpoint, holds a flat 20 requests per second on every plan, and returns up to 20 tweets with full metrics and author profiles per /user-tweets call, at roughly $0.0001 per tweet on the Pro plan. For batches of known IDs, /tweet-info-bulk accepts 100 tweets in a single request, which keeps large collections cheap.

Can a third-party API replace the X API v2 for analytics?

For reading public engagement, largely yes. Sorsa API returns the same six public metrics for any public account and bundles the full author profile in every tweet response at no extra cost, which the official API bills separately. The genuine limits: it is read-only, so it does not post or send DMs, and as a public-data API it does not expose the owner-only organic_metrics breakdown. For analysis workloads those rarely matter.

Can you get historical tweet analytics through an API?

Yes. Both the official X API v2 full-archive search and Sorsa's /search-tweets can retrieve tweets going back to 2006, and every returned tweet carries its current engagement metrics. The numbers reflect the present state, so you see how many likes a 2020 post has now, not how many it had at the time. To track change over time, store periodic snapshots in your own database.

Getting started

If you want to explore what is possible before writing code, start with the free tools that need no API key:

• The API playground lets you test any endpoint from the browser and see live tweet data with every metric.
• The engagement-rate calculator returns the rate for any public account from its recent tweets.

When you are ready for code, get an API key and follow the quickstart to make your first request in a few minutes, with no app approval and a flat 20 requests per second from the first plan up. The Starter plan covers 10,000 requests at $49 and Pro covers 100,000 at $199. For a full cost breakdown against the official API, see Twitter API pricing in 2026, and for setup questions the team is reachable on Discord.

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

How we put this together: the code and metric mappings come from our own work building and operating Sorsa's API and from testing requests against the live official endpoints. For the official side we checked X's public_metrics data-dictionary and metrics documentation and the X Ads API analytics docs for the campaign-metrics and 90-day reporting details. The native-dashboard access split, Premium for account-level versus free per-post, was confirmed against current X analytics guides published in early 2026, and the X API pay-per-use rates come from our maintained pricing reference, cross-checked against X's developer pricing. Pricing and access on X change often, so every figure here was re-verified on June 6, 2026. More about who maintains this is on the about page.