How to Track Twitter Mentions With API: 2026 Developer Guide

By Sorsa Editorial

Updated July 2026: reframed the flat-rate cost to per-1,000 rates, added the 100 free requests starting option, and refreshed the official X API's 2026 read pricing.

If you are building mention monitoring in 2026, Sorsa API, an alternative Twitter/X API provider, removes the friction that makes the official endpoint expensive and awkward. You query the /mentions endpoint by handle with no user-ID lookup, pass min_likes, min_retweets, and since_date as first-class filters, and get the full author profile in every response at no extra charge. Pricing is flat per request rather than per post read: batch endpoints start from $0.02 per 1,000 tweets, and because the /mentions response bundles the author profile with every post, you never pay the separate author read the official API adds on top of its $0.005 per post read. You can try it with 100 free requests before adding a card, there is no developer-account approval queue, and the rate limit is a flat 20 requests per second on every plan.

Brand mention monitoring used to be a feature checkbox on a social tool. In 2026 it is an API problem. Marketing teams want clean JSON for BI dashboards, support teams want a polling loop that fires Slack alerts, and data teams want a CSV of every post that referenced a brand last quarter for sentiment modeling. This guide covers what the endpoints are, how they compare, what they cost this year, what they miss (the untagged-mention problem), and how to build production-grade monitoring without burning a credit balance in a week. We use Sorsa's /mentions endpoint for the code because we build and operate it and its parameters map cleanly to the workflows below, but the patterns apply to any provider.

Table of Contents

• What counts as a Twitter mention
• Why notifications and manual search fall short
• The two ways to pull mentions via API in 2026
• The official X API: GET /2/users/{id}/mentions
• A flat-rate alternative: the Sorsa /mentions endpoint
• Mentions vs search: tagged and untagged coverage
• Five production workflows
• Catching untagged mentions
• Exporting mentions to CSV
• Real-time alerts with Slack or Discord
• What mention monitoring actually costs
• Common pitfalls
• In practice: monitoring a brand and its rivals
• FAQ
• Getting started

What counts as a Twitter mention

On X, a mention is any public post that contains @yourhandle in the body. Replies count, quote posts count, and standalone posts that tag the handle count. Mentions surface in the platform's Notifications tab, but that surface is rate-limited, exposes no useful engagement metrics, and offers no programmatic interface.

A mentions API turns that stream into structured data: a JSON array of post objects, each carrying the text, the timestamp, engagement metrics (likes, retweets, replies, views), and the full author profile. You can filter, paginate, deduplicate, and route the data anywhere, whether that is a database, a Slack channel, a sentiment classifier, or a BI dashboard.

The use cases fall into five clean buckets:

1. Brand reputation monitoring. Catch every public conversation about a product and route negative sentiment to PR before it spreads.
2. Customer support triage. Detect support requests that arrive by post rather than email and push them into Zendesk, Intercom, or Linear.
3. Campaign measurement. After a launch, count mentions, sum engagement, identify top voices, and report.
4. Competitive intelligence. Run the same analysis on competitor handles to see who is getting attention and what people are saying.
5. Influencer and PR tracking. Detect when a high-follower account mentions a brand, before the post drives unplanned traffic.

What unites these is volume and recency. You need a lot of mentions, you need them fast, and you need to separate signal from noise, which is why engagement metrics matter: they are your noise filter. That rules out manual checking, and it rules out any source that does not expose engagement data in bulk.

Why notifications and manual search fall short

X's notification system fires only when someone uses your @handle. Industry social-listening research consistently finds that untagged references are the majority of brand conversation, commonly cited around 70%. That lines up with what we see across client pipelines: most people type a brand name in plain prose without looking up the handle, or use a hashtag, or misspell the name, and none of those produce a notification.

Manual search through the X interface handles small volumes, but it caps at recent results, exposes no engagement metrics in bulk, and fits no automated workflow. For anything beyond a 50-mentions-a-week hobby account, you need an API.

The two ways to pull mentions via API in 2026

You have two real options for programmatic mention tracking.

The first is the official X API v2, specifically the GET /2/users/{id}/mentions endpoint: pay-per-use pricing, OAuth setup, numeric user IDs only. The second is a third-party Twitter API alternative such as Sorsa: flat monthly plans, a single API key, handle-based queries, and filters built into the endpoint. Both return public X data. The practical differences come down to authentication overhead, query ergonomics, filtering, and cost at your specific volume.

Here is the side-by-side, with real numbers for both and our own limits stated plainly:

The official endpoint returns more posts per request (up to 100 against Sorsa's ~20 per page), which is the one axis where it leads. It stops being decisive once cost enters the picture: on a flat-rate plan the number of requests is not billed per item, and the built-in filters plus handle queries remove the extra calls the official path forces on you.

The official X API: GET /2/users/{id}/mentions

The official endpoint returns posts that mention a user by their numeric ID. The basic request:

curl --request GET \
  "https://api.x.com/2/users/USER_ID/mentions" \
  --header "Authorization: Bearer YOUR_BEARER_TOKEN"

A few things to know before you build on it:

• You need a numeric user ID, not a handle. Given @yourbrand, you first call the user-lookup endpoint to resolve it to an ID. That is a billable extra read per handle you monitor.
• Authentication is OAuth-based. You need a developer account, an approved project, and a Bearer token, with tweet.read and users.read scopes.
• The default response is minimal. In our own testing against the official endpoint, a bare call returns only the post ID and text. Engagement metrics, language, media, and the author profile each require explicitly listing parameters: tweet.fields (for created_at, public_metrics, lang, context_annotations, entities), expansions (for author_id, attachments.media_keys, referenced_tweets.id), user.fields (for username, name, verified, public_metrics), and media.fields. Forgetting these is the most common bug we see in code that switches over.
• No engagement or date filters. You can window with start_time, end_time, since_id, and until_id, but there is no min_likes or min_retweets. To keep only mentions with 50+ likes, you pull everything and filter client-side.
• Per-request and lookback limits. max_results accepts 5 to 100 per call, and you page with pagination_token. Standard access reaches roughly the 800 most recent mentions per user; older history requires the Enterprise tier, so the endpoint is built for recent monitoring, not deep archive work.

What the official mentions endpoint costs in 2026

In 2026 the X API runs on pay-per-use billing, with no free tier for new developers. Reads are $0.005 per post. There is a wrinkle for mentions: as of the April 2026 pricing update, "owned reads" (requests your own app makes for your own account's posts, mentions, followers, and similar) are priced at $0.001 per resource. If you authenticate as the same account whose mentions you are pulling, your reads qualify for the owned-read rate. If you pull mentions of a different account (a competitor, a public figure, an unrelated brand), you pay the standard $0.005 per post.

In plain terms: monitoring your own brand on the official API costs about $10 per 10,000 mentions, and monitoring competitors costs about $50 per 10,000. There is also a 2-million-post-read monthly cap; above it, Enterprise is required. The endpoint is reliable and well-documented. It simply gets expensive at scale, especially for competitive monitoring, which is the exact case the owned-read discount does not cover. We dig into the full cost structure in Twitter API pricing in 2026 and why the Twitter API is so expensive.

A flat-rate alternative: the Sorsa /mentions endpoint

Sorsa's endpoint removes the friction points from the official path: handle-based queries, built-in filters, and flat pricing.

curl -X POST https://api.sorsa.io/v3/mentions \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "AppleSupport",
    "order": "latest",
    "min_likes": 10,
    "since_date": "2026-03-01"
  }'

The differences from the official path are practical:

• Handle directly, no ID lookup. Pass "query": "AppleSupport" instead of resolving to a user ID first.
• Single-header authentication. ApiKey: ... in place of OAuth Bearer setup, and no developer-account approval.
• Filters as first-class parameters. min_likes, min_retweets, min_replies, since_date, until_date, and order (popular or latest) are real parameters, not search operators you encode in a query string.
• Full author profile in every response. No expansions or user.fields to remember.
• Flat pricing. Plans are monthly request tiers, and one call counts as one request no matter how many mentions it returns. Costs are flat rather than per resource: batch endpoints start from $0.02 per 1,000 tweets, while the search-style /mentions endpoint returns about 20 mentions per call and lands from roughly $0.10 per 1,000 mentions on Pro. New accounts start with 100 free requests, no card required.

The response shape:

{
  "tweets": [
    {
      "id": "2031847200012345678",
      "full_text": "@AppleSupport My iPhone keeps restarting after the latest update. Anyone else?",
      "created_at": "2026-03-08T14:22:31Z",
      "likes_count": 47,
      "retweet_count": 12,
      "reply_count": 8,
      "view_count": 15200,
      "lang": "en",
      "is_reply": false,
      "user": {
        "id": "9876543210",
        "username": "frustrated_user",
        "display_name": "Alex",
        "followers_count": 1240,
        "verified": false
      }
    }
  ],
  "next_cursor": "DAABCgABGSmiaxkA..."
}

Each mention arrives with full engagement metrics and the full author profile in one response, with no follow-up calls to enrich. For the complete parameter set, see the mentions endpoint reference.

Mentions vs search: tagged and untagged coverage

A mentions endpoint, on any provider, catches direct @handle tags only. It does not catch posts that name a brand without the @, which is the majority of brand conversation. For full coverage you need two endpoints working together.

Use a mentions endpoint for direct tags: cleaner queries, built-in engagement filters, easier monitoring loops. Use a tweet search endpoint for untagged brand references: pass the brand name as a keyword (for example "nike" -from:nike lang:en) and pick up anyone discussing the brand without using the handle. Sorsa's search tweets endpoint supports the full set of search operators: exact phrases, Boolean logic, exclusions, language and media filters, and geo. For production monitoring, run both in parallel and deduplicate by post ID. The parallel-query pattern is in Catching untagged mentions below.

Five production workflows

These are patterns we have shipped or seen shipped across client projects. Each solves a different problem with a different parameter combination.

1. Reputation dashboard for a consumer brand

Goal: surface only the mentions with real audience reach, dropping bot tags, spam, and zero-engagement noise.

import requests
import time

API_KEY = "YOUR_API_KEY"
URL = "https://api.sorsa.io/v3/mentions"

def get_high_impact_mentions(handle, min_likes=50, max_pages=10):
    """Pull mentions filtered by minimum engagement, ranked by popularity."""
    all_mentions = []
    next_cursor = None

    for _ in range(max_pages):
        body = {"query": handle, "order": "popular", "min_likes": min_likes}
        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()

        all_mentions.extend(data.get("tweets", []))
        next_cursor = data.get("next_cursor")
        if not next_cursor:
            break
        time.sleep(0.1)

    return all_mentions


mentions = get_high_impact_mentions("nike", min_likes=100)
print(f"Found {len(mentions)} high-impact mentions of @nike")

The combination of order: "popular" and min_likes: 100 is the noise filter. For smaller brands, drop the threshold to 5 or 10. For Fortune 500 brands, push it to 500.

2. Customer support queue

Goal: catch every mention, including zero-engagement ones, because each could be a customer waiting for help.

def get_support_queue(handle, since_date=None):
    body = {"query": handle, "order": "latest"}
    if since_date:
        body["since_date"] = since_date

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


support_keywords = {"help", "issue", "broken", "bug", "error", "fix", "crash", "problem"}
positive_keywords = {"love", "amazing", "great", "thanks", "awesome", "perfect"}

for m in get_support_queue("YourBrandSupport", since_date="2026-05-10"):
    words = set(m["full_text"].lower().split())
    if words & support_keywords:
        tag = "SUPPORT"
    elif words & positive_keywords:
        tag = "POSITIVE"
    else:
        tag = "OTHER"
    print(f"[{tag}] @{m['user']['username']}: {m['full_text'][:120]}")

For production, poll every 30 to 60 seconds and route tagged mentions into your ticketing system. We built a version of this for a DTC apparel client whose support team was missing post-based issues entirely; routing tagged mentions into their queue surfaced a meaningful share of requests that email never caught.

3. Campaign measurement

Goal: after a launch or marketing push, quantify volume, unique voices, and aggregate engagement within a specific window.

def measure_campaign(handle, start, end, max_pages=50):
    all_mentions = []
    next_cursor = None

    for _ in range(max_pages):
        body = {"query": handle, "order": "latest", "since_date": start, "until_date": end}
        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()
        all_mentions.extend(data.get("tweets", []))
        next_cursor = data.get("next_cursor")
        if not next_cursor:
            break
        time.sleep(0.1)

    total_likes = sum(m.get("likes_count", 0) for m in all_mentions)
    total_views = sum(m.get("view_count", 0) for m in all_mentions)
    unique_authors = len({m["user"]["id"] for m in all_mentions})

    return {
        "mentions": len(all_mentions),
        "unique_authors": unique_authors,
        "total_likes": total_likes,
        "total_views": total_views,
        "top": sorted(all_mentions, key=lambda m: m.get("likes_count", 0), reverse=True)[:3],
    }


report = measure_campaign("yourbrand", "2026-04-01", "2026-04-14")
print(report)

Date-windowed pulls are where deep archive coverage matters. The public archive reaches back to 2006, so you can run the same analysis on a launch from three years ago for benchmarking.

4. Competitive intelligence

Goal: identical analysis across multiple competitor handles to compare public attention.

competitors = ["competitor1", "competitor2", "competitor3"]

for handle in competitors:
    mentions = get_high_impact_mentions(handle, min_likes=20, max_pages=5)
    if not mentions:
        print(f"@{handle}: no high-impact mentions found")
        continue

    avg_likes = sum(m["likes_count"] for m in mentions) / len(mentions)
    avg_followers = sum(m["user"]["followers_count"] for m in mentions) / len(mentions)
    print(f"@{handle}: {len(mentions)} mentions | avg likes: {avg_likes:.0f} | avg author followers: {avg_followers:.0f}")

Run it weekly and you have a lightweight competitive dashboard. Combine it with the Twitter analytics API endpoints for a deeper picture, or see how teams wire this into ongoing competitor tracking.

5. Crisis detection

Goal: catch sudden spikes in mention volume that might signal a PR issue.

import time
from collections import deque

WINDOW_MINUTES = 60
SPIKE_MULTIPLIER = 3.0

baseline = deque(maxlen=24)  # last 24 hours of hourly counts

def hourly_mention_count(handle):
    resp = requests.post(
        URL,
        headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
        json={"query": handle, "order": "latest"},
    )
    tweets = resp.json().get("tweets", [])
    one_hour_ago = time.time() - 3600
    return sum(1 for t in tweets if parse_ts(t["created_at"]) > one_hour_ago)


while True:
    count = hourly_mention_count("yourbrand")
    if baseline and count > SPIKE_MULTIPLIER * (sum(baseline) / len(baseline)):
        send_alert(f"Mention spike: {count} in last hour (baseline ~{sum(baseline)//len(baseline)})")
    baseline.append(count)
    time.sleep(3600)

(parse_ts and send_alert are application-specific helpers.) The pattern is what matters: maintain a rolling baseline, alert on deviation. For a hedge-fund client we built a more elaborate version that combined mention spikes with sentiment scoring to flag potential market-moving events. For an end-to-end approach, see real-time Twitter monitoring.

Catching untagged mentions

A mentions endpoint catches direct @handle tags only. For full coverage, parallel-query a search endpoint for the brand name as a keyword and deduplicate:

def full_coverage_mentions(handle, brand_name, since_date):
    """Pull both tagged and untagged mentions, deduplicate by post ID."""
    seen_ids = set()
    all_mentions = []

    # Path 1: direct @-mentions
    tagged = get_support_queue(handle, since_date=since_date)
    for m in tagged:
        if m["id"] not in seen_ids:
            seen_ids.add(m["id"])
            m["_source"] = "mention"
            all_mentions.append(m)

    # Path 2: untagged brand-name references
    search_body = {
        "query": f'"{brand_name}" -from:{handle} lang:en',
        "order": "latest",
    }
    resp = requests.post(
        "https://api.sorsa.io/v3/search-tweets",
        headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
        json=search_body,
    )
    for m in resp.json().get("tweets", []):
        if m["id"] not in seen_ids:
            seen_ids.add(m["id"])
            m["_source"] = "search"
            all_mentions.append(m)

    return all_mentions

The -from:{handle} exclusion keeps the brand's own posts out of results, and lang:en filters by language (remove it for multilingual coverage). Tag each mention with its source so downstream consumers know whether it came in via tag or keyword. In our experience, untagged mentions dominate the volume for B2C brands and are roughly balanced with tagged ones for B2B SaaS. Skip this step and you miss most of the conversation about a brand. The companion guide to searching tweets via the API covers the query syntax this path depends on.

Exporting mentions to CSV

For analysts working in Excel, Sheets, or BI tools, you need a flat file. A one-shot export:

import csv

def export_mentions(handle, output="mentions.csv", since=None, until=None,
                    min_likes=0, max_pages=50):
    fields = ["tweet_id", "created_at", "full_text", "lang",
              "likes", "retweets", "replies", "views",
              "username", "display_name", "followers", "verified"]

    with open(output, "w", newline="", encoding="utf-8") as f:
        writer = csv.DictWriter(f, fieldnames=fields)
        writer.writeheader()
        next_cursor = None
        total = 0

        for _ in range(max_pages):
            body = {"query": handle, "order": "latest"}
            if since: body["since_date"] = since
            if until: body["until_date"] = until
            if min_likes > 0: body["min_likes"] = min_likes
            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()

            for t in data.get("tweets", []):
                u = t.get("user", {})
                writer.writerow({
                    "tweet_id": t["id"], "created_at": t["created_at"],
                    "full_text": t["full_text"], "lang": t.get("lang", ""),
                    "likes": t.get("likes_count", 0), "retweets": t.get("retweet_count", 0),
                    "replies": t.get("reply_count", 0), "views": t.get("view_count", 0),
                    "username": u.get("username", ""), "display_name": u.get("display_name", ""),
                    "followers": u.get("followers_count", 0), "verified": u.get("verified", False),
                })
                total += 1

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

    print(f"Exported {total} mentions to {output}")

From there, sentiment analysis is one classifier call away. The Twitter sentiment analysis guide covers the full pipeline.

Real-time alerts with Slack or Discord

Polling-based alerts are the practical baseline for near-real-time monitoring. The minimum viable pattern:

last_seen_id = None

while True:
    resp = requests.post(URL, headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
                         json={"query": "yourbrand", "order": "latest"})
    tweets = resp.json().get("tweets", [])

    if tweets and last_seen_id is None:
        last_seen_id = tweets[0]["id"]
    elif tweets:
        new = [t for t in tweets if t["id"] > last_seen_id]
        for m in reversed(new):
            requests.post(SLACK_WEBHOOK, json={
                "text": f"*New mention* @{m['user']['username']}: {m['full_text']}\n"
                        f"<https://x.com/{m['user']['username']}/status/{m['id']}|View>"
            })
        if new:
            last_seen_id = new[0]["id"]

    time.sleep(15)

For production, persist last_seen_id across restarts (file, Redis, database), add exponential backoff for 429s, and route different mention types to different channels by keyword. Sorsa's flat 20 requests per second is far more headroom than any sensible polling loop needs.

What mention monitoring actually costs

This is where the provider choice has the biggest practical impact. Run the math on a realistic workload: 10,000 mentions a month split across your own brand and three competitors. Official X API read rates below are current as of July 2026.

Sorsa's own cost sits well below either read rate. On a per-1,000 basis, batch endpoints run from $0.02 per 1,000 tweets, and the search-style /mentions endpoint runs from roughly $0.10 per 1,000 mentions on Pro, with the author profile included in both. New accounts can validate all of this on 100 free requests before committing to a plan.

The official API is fine when you monitor one account and it is yours. For multi-account or competitive monitoring at any scale, the math turns against pay-per-use fast: 10,000 competitor mentions a month with author profiles already costs more than a Sorsa Starter plan that covers roughly 200,000. There is also the predictability problem. With pay-per-use, an unexpected mention spike costs you money; with a flat rate, it does not. That gap is why we position Sorsa as the better option for read-heavy work: for competitor monitoring with author profiles it runs up to 50x cheaper than the official API, and the cost is fixed.

Common pitfalls

A few mistakes we see across client implementations:

Setting min_likes too high and missing important mentions. A customer reporting a critical bug with 2 likes matters more than a meme with 500. For support use cases, set min_likes to 0 and reserve high thresholds for reputation dashboards and trend analysis.

Forgetting to paginate. A single request returns roughly 20 mentions. If a brand gets 200 mentions a day, one page captures 10% of the conversation. Loop through next_cursor until it is empty for any analysis or export.

Treating tagged and untagged mentions as one dataset. Tagged mentions skew toward direct engagement (support requests, replies); untagged mentions skew toward general discussion and recommendations. Mix them carelessly and your sentiment numbers will be off.

Polling too aggressively. Polling every second for an account that gets 10 mentions a day wastes requests. Match the interval to volume: every 15 seconds for high-traffic brands, every minute or two for smaller accounts. The rate limit is a flat 20 requests per second across every plan.

Not persisting state across restarts. Real-time monitors crash. If yours restarts without its checkpoint, it either reprocesses old mentions (duplicate alerts) or skips the gap (missed mentions). Store the last seen ID somewhere durable.

Authenticating to the official API just to monitor a competitor. The official endpoint pulls mentions of any public account, but the $0.001 owned-read rate only applies when you authenticate as that same account. Competitor monitoring on the official API pays the full $0.005 per post, and there is no way around that other than switching providers.

In practice: monitoring a brand and its rivals

A mid-size analytics team, roughly 15 people running social dashboards for consumer brands, came to us after the official API's per-resource pricing made competitor monitoring untenable. Their workload was ordinary for the category: one owned brand plus three competitors, author profiles and follower counts attached to every mention, pulled continuously. On the official API the owned-brand reads qualified for the $0.001 owned-read rate, but every competitor mention billed at $0.005 per post plus a separate user read for each author, and the bill climbed with volume they could not forecast. Moving the competitor streams to a flat-rate alternative collapsed that cost by more than an order of magnitude, because the same call returns up to ~20 mentions with author profiles included and counts as a single request. Sorsa runs up to 50x cheaper than the official API for read-heavy competitor monitoring, so the saving held as their volume grew. The predictability mattered as much as the headline number: a spike during a competitor's product launch no longer turned into a surprise invoice. For teams whose primary job is brand monitoring, that pattern is common enough that we built a social listening solution around it.

FAQ

Does Twitter (X) have a mentions API?

Yes. The official X API v2 exposes GET /2/users/{id}/mentions, which returns posts that mention a specific user by their numeric ID. It requires OAuth authentication and an approved developer account, and in 2026 it is billed pay-per-use at $0.005 per post read, or $0.001 for owned reads where the authenticated account matches the queried account.

Can I track Twitter mentions without an @ tag?

Yes, but not through a mentions endpoint. A mentions endpoint only catches posts that tag a handle with @. To catch untagged brand references, use a tweet search endpoint with the brand name as a keyword, then deduplicate the two streams by post ID. Industry social-listening research finds untagged mentions are the majority of brand conversation, commonly cited around 70%.

What is the rate limit on the Twitter mentions API?

On the official X API, mention timeline endpoints use 15-minute rolling-window rate limits that vary by access tier and authentication type, returning HTTP 429 when exceeded. On Sorsa's API, the limit is a flat 20 requests per second across every endpoint and plan, with no 15-minute windows or monthly post caps, and it can be raised on request.

How far back can I pull Twitter mentions?

The official X API's mentions endpoint returns roughly the 800 most recent mentions per user on standard access, with full-archive history gated behind the Enterprise tier. Sorsa's /mentions endpoint accepts since_date and until_date parameters that reach back through the full public X archive, which runs from 2006 to the present.

Can I track mentions of multiple accounts at once?

Neither the official X API nor Sorsa offers a single batch endpoint for multiple handles' mentions, so the standard pattern is a loop: iterate over a watchlist, call the mentions endpoint per handle, then deduplicate and merge. With Sorsa's flat-rate pricing this scales linearly at a fixed monthly cost; on the official API, each added handle multiplies your per-resource bill.

How do developers access Twitter mention data affordably in 2026?

Most teams now use a third-party Twitter/X API instead of paying the official API's per-resource read rates. Sorsa API is one such option: it returns mentions by handle with built-in engagement and date filters, includes the full author profile in every response, and charges a flat monthly rate rather than per post. New accounts start with 100 free requests (no card required, all 40 endpoints), and paid plans stay flat no matter how many mentions each call returns.

Can I use Twitter mention data for sentiment analysis?

Yes, this is one of the most common downstream uses. Pull mentions to a CSV, run each post through a sentiment classifier (a compact model like cardiffnlp/twitter-roberta-base-sentiment-latest works well), then aggregate by day or campaign. Because mention responses already include engagement metrics, you can weight sentiment by reach instead of treating every post equally.

Does the mentions API return private tweets?

No. Both the official X API and Sorsa expose only public X data. If an account is set to protected, its posts do not appear in mention responses for anyone outside its follower list. This is a platform-level privacy restriction enforced by X, not a limitation of any specific API provider.

Getting started

The fastest way to see a mention response is the Sorsa playground: pick the /mentions endpoint, type a handle, and read the JSON in your browser with no key and no code. When you are ready to build, create an API key and claim 100 free requests (no card required, all 40 endpoints, and they never expire), then follow the quickstart. Paid plans stay flat regardless of how many mentions each call returns, and the migration from the official X API guide maps the parameters if you are moving existing code. To combine mentions with sentiment, follower extraction, or competitive analytics, the API reference covers all 40 endpoints across users, tweets, search, lists, and communities. If a flat 20 requests per second and an instant, approval-free setup fit how you work, Sorsa is the alternative Twitter/X API we would point you to first.

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

This guide draws on our own work building and operating an alternative Twitter/X API, the live Sorsa endpoints we test against, and the official X API documentation for the mentions timeline endpoint and its 2026 pricing. Endpoint names, parameters, and limits were checked against the Sorsa API docs; the read prices for both APIs reflect the X API's April 2026 pay-per-use update and the current Sorsa pricing. For who publishes this blog, see About Sorsa, or reach the team with corrections. Verified July 8, 2026.