How to Track Twitter Mentions With API: The 2026 Developer's Guide

Key Takeaway

A Twitter mentions API lets you programmatically retrieve every public post that tags a given handle. The official X API exposes GET /2/users/{id}/mentions at $0.005 per tweet read with OAuth setup. Third-party alternatives like Sorsa API offer the same data with a single API key, built-in engagement and date filters, and flat-rate monthly pricing instead of per-call billing.

Brand mention monitoring used to be a checkbox on a social listening tool's feature list. In 2026, it's an API problem. Marketing teams want clean JSON they can push into BI dashboards. Support teams want a polling loop that fires Slack alerts for new mentions. Data scientists want a CSV of every tweet that referenced a brand last quarter for sentiment modeling.

This guide covers the practical side: what endpoints exist, how they compare, what they cost in 2026, what they miss (the "untagged" problem), and how to build production-grade mention monitoring without burning through a credit balance in a week. I'll use the Sorsa API /mentions endpoint for code examples because it's our product and because the parameter set maps cleanly to the workflows below, but the architectural patterns apply regardless of which provider you pick.

I've been working with Twitter APIs since the v1.1 days, and I've helped 40+ companies rebuild their data pipelines since the 2023 pricing overhaul. Mention monitoring is one of the workloads where the choice of provider matters most, because volumes are high and the data has a short half-life. Get it wrong and you either miss conversations or spend ten times what you need to.

Table of Contents

• What "tracking mentions" actually means
• Why notifications and manual search aren't enough
• The two API paths in 2026
• Official X API: GET /2/users/{id}/mentions
• Alternative: Sorsa API /mentions endpoint
• /mentions vs /search-tweets: which to use when
• Five production workflows
• Catching untagged mentions
• Exporting mentions to CSV
• Real-time alerts via Slack or Discord
• Cost reality check
• Common pitfalls
• FAQ
• Getting started

What "tracking mentions" actually means

On X, a "mention" is any public post containing @yourhandle in the body. Replies count. Quote tweets count. Standalone tweets that tag you count. Mentions surface in the platform's Notifications tab, but that surface is rate-limited, doesn't expose engagement metrics in a useful way, and offers no programmatic interface.

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

The use cases break into five clean buckets:

1. Brand reputation monitoring. Catch every public conversation about your product and route negative sentiment to PR before it spreads.
2. Customer support triage. Detect support requests that come in via tweet 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 back.
4. Competitive intelligence. Run the same analysis on competitor handles to see who's getting attention and what people are saying.
5. Influencer and PR tracking. Detect when a high-follower account mentions you, before the tweet drives traffic you didn't plan for.

What unites these is volume and recency. You need a lot of mentions, you need them fast, and you need to be able to filter the signal from the noise. That rules out manual checking. It also rules out anything that doesn't expose engagement metrics, because engagement is your noise filter.

Why notifications and manual search aren't enough

X's notification system fires only when someone uses your @handle. According to Brand24's 2025 research, over 90% of brand mentions don't tag the account directly. That number lines up with what I've seen across client pipelines: most users type the brand name in plain prose without bothering to look up the handle, or they use a hashtag, or they misspell the name. Indirect mentions (brand name in prose without @) are 1.5 to 3 times the volume of direct @-mentions for established brands and never produce notifications.

Manual search via the X UI handles small volumes, but it caps at recent results, doesn't expose engagement metrics in bulk, and obviously doesn't fit any kind of automated workflow. For anything beyond a 50-mentions-a-week hobby account, you need an API.

The two API paths in 2026

You have two real options for programmatic mention tracking:

1. The official X API v2 - specifically, the GET /2/users/{id}/mentions endpoint. Pay-per-use pricing, OAuth setup, numeric user IDs only.
2. A third-party API like Sorsa - flat-rate monthly plans, single API key, handle-based queries, additional filters built into the endpoint.

Disclosure: Sorsa API is our product. I've tried to keep the comparison below factual and verifiable, but you should test any provider against your own workload before committing.

Both approaches return public X data. The difference comes down to four things: authentication overhead, query ergonomics, filtering capability, and cost at your specific volume. Let's look at each.

Official X API: GET /2/users/{id}/mentions

The official endpoint is documented at developer.x.com. The basic request shape:

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

A few things to know upfront:

• You need a numeric user ID, not a handle. If you have @yourbrand, you first call GET /2/users/by/username/yourbrand to resolve it to a numeric ID. That's a billable extra call per handle you want to monitor.
• Authentication is OAuth-based. You need a developer account, an approved project, and a Bearer Token from the Developer Console.
• Default response is minimal. You get tweet ID and text only. To pull engagement metrics, author profile, language, or media, you specify tweet.fields, expansions, and user.fields parameters explicitly. Forgetting these is the most common bug I see in client code.
• No built-in engagement or date filters. You can pass start_time, end_time, since_id, and until_id for windowing, but there's no min_likes or min_retweets parameter. If you want only mentions with 50+ likes, you pull everything and filter client-side.

2026 pricing for the mentions endpoint

In 2026, the X API moved to pay-per-use billing. As of February 2026, pay-per-use is the default X API pricing for new developers: $0.01 per post created, $0.005 per post read, capped at 2 million reads per month. The free tier is discontinued.

There's a wrinkle for mentions specifically: as of April 20, 2026, "owned reads" (requests made by your own developer app for your own posts, bookmarks, followers, likes, lists, and more) are priced at $0.001 per resource. If you authenticate as the same account you're pulling mentions for, your mention reads qualify for the owned-read rate. If you're pulling mentions of a different account (a competitor, a public figure, an unrelated brand), you pay the standard $0.005 per tweet.

Translation: monitoring your own brand on the official API costs about $10 per 10,000 mentions. Monitoring competitors costs $50 per 10,000 mentions. There's also a 2 million post read per month cap; above that threshold, Enterprise is required.

The endpoint works. It's reliable. It just gets expensive when you scale, especially for competitive monitoring.

Alternative: Sorsa API /mentions endpoint

The Sorsa endpoint is designed to remove the friction points from the official path: handle-based queries, built-in filters, 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"
  }'

Key differences from the official path:

• 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.
• Built-in filters. min_likes, min_retweets, min_replies, since_date, until_date, and order (popular vs latest) are first-class parameters, not search operators you encode in a query string.
• Full author profile in every response. No expansions or user.fields to remember.
• Flat-rate pricing. Pricing is monthly subscription tiers. The Pro plan ($199/mo) gives you 100,000 requests, and each request returns up to ~20 mentions, so you're looking at roughly $0.0001 per mention.

Response shape:

{
  "tweets": [
    {
      "id": "2031847200012345678",
      "full_text": "@AppleSupport My iPhone keeps restarting after the latest update. Anyone else?",
      "created_at": "Sat Mar 08 14:22:31 +0000 2026",
      "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 full author profile in one response. No follow-up calls to enrich. For a complete parameter reference, see the /mentions endpoint docs.

/mentions vs /search-tweets: which to use when

This distinction matters more than most developers realize. The /mentions endpoint (on any provider) catches direct @handle tags. It does not catch tweets that name your brand without the @. As discussed above, that's the majority of brand conversation.

For complete coverage, you need both:

• /mentions for direct tags. Cleaner queries, built-in engagement filters, easier to set up monitoring loops.
• /search-tweets for untagged brand references. You pass the brand name as a keyword (e.g., "nike" -from:nike lang:en) and pick up anyone discussing the brand without using the handle.

The Search Tweets endpoint supports full Twitter search operators: exact phrases, Boolean logic, exclusions, language filters, media filters, geo. For production mention monitoring, run both endpoints in parallel and deduplicate by tweet ID.

I'll show a parallel-query pattern in the Catching untagged mentions section below.

Five production workflows

These are the patterns I've shipped (or seen shipped) across client projects. Each one solves a different problem and uses different parameter combinations.

1. Reputation dashboard for a consumer brand

Goal: surface only the mentions that have actual audience reach. Drop 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 ones with zero engagement, because each one 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. I built a version of this for a DTC apparel client in 2024; their support team caught about 18% of incoming issues via Twitter that would have otherwise gone unnoticed.

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 also where the historical data coverage matters. Sorsa's archive goes 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 on 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 this weekly and you have a lightweight competitive dashboard. Combine with the Twitter analytics API endpoints for a deeper picture. For a more comprehensive approach, see the competitor analysis docs.

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 detected: {count} mentions 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 in 2024 we built a more elaborate version that combined mention spikes with sentiment scoring to flag potential market-moving events.

Catching untagged mentions

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

def full_coverage_mentions(handle, brand_name, since_date):
    """Pull both tagged and untagged mentions, deduplicate by tweet 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 prevents the brand's own tweets from polluting results. lang:en filters by language; remove for multilingual coverage. Tag each mention with its source so downstream consumers know whether it came in via tag or keyword.

In my experience, untagged mentions typically dominate the volume for B2C brands and are roughly balanced with tagged mentions for B2B SaaS products. Don't skip this step. Without monitoring untagged mentions, you miss the majority of conversations about your brand.

Exporting mentions to CSV

For analysts working in Excel, Sheets, or BI tools, you need a flat file. Here's 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. See the Twitter sentiment analysis article for the full pipeline.

Real-time alerts via Slack or Discord

Polling-based real-time alerts deserve their own deep-dive (I'll publish one separately), but the minimum viable pattern is straightforward:

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 consider routing different mention types to different channels based on keyword matching.

Cost reality check

This is where the provider choice has the biggest practical impact. Let's run the math on a realistic mention-monitoring workload: 10,000 mentions per month split across your own brand and three competitors.

The official API is fine if you're monitoring one account and the account belongs to you. For multi-account or competitive monitoring at any scale, the math turns against pay-per-use quickly. A workload of 10,000 mentions a month with author profiles and follower counts on each is where pay-per-use starts to bite; add competitor monitoring on top, or any kind of historical research, and you'll see the bill climb fast.

There's also the predictability issue. With pay-per-use, an unexpected mention spike costs you money. With flat-rate, it doesn't. For deeper analysis on this, see Twitter API pricing 2026 and why is Twitter API so expensive.

Common pitfalls

A few mistakes I see across client implementations:

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

Forgetting to paginate. A single request returns roughly 20 mentions. If your brand gets 200 mentions a day, a single page captures 10% of the conversation. Always loop through next_cursor until empty for analysis or export. See pagination patterns.

Treating tagged and untagged mentions as the same dataset. /mentions and /search-tweets results have different bias profiles. 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 per day wastes requests. Match your polling interval to mention volume: every 15 seconds for high-traffic brands, every minute or two for smaller accounts. Sorsa's rate limit is 20 requests per second, which is more than any sensible polling loop needs.

Not persisting state across restarts. Real-time monitors crash. If yours restarts without remembering 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 mentions endpoint pulls mentions of any public account, but the "owned read" pricing only applies when you authenticate as the same account. Competitor monitoring on the official API pays full price ($0.005/tweet), and there's no way around that other than switching providers.

FAQ

Does Twitter have a mentions API?

Yes. The official X API v2 exposes GET /2/users/{id}/mentions, which returns posts mentioning a specific user by their numeric ID. It requires OAuth Bearer Token authentication and a Developer Console account. As of February 2026, it's billed pay-per-use at $0.005 per resource for general reads, or $0.001 per resource for "owned reads" where the authenticated user matches the queried user.

How do I track mentions of my brand on Twitter for free?

X's notification system and manual search via the X website are free but limited: notifications only fire on direct @-tags (missing the 90%+ of mentions without tags), and search caps at recent results. For genuinely free programmatic access, no current API provider offers a free tier large enough for production monitoring. The cheapest viable path is a low-tier subscription on a third-party API like Sorsa's Starter plan at $49/month for ~200,000 mentions.

Can I track Twitter mentions without an @ tag?

Yes, but not via the /mentions endpoint. Use a tweet search endpoint with the brand name as a keyword. On the official X API that's GET /2/tweets/search/recent. On Sorsa it's POST /v3/search-tweets. Run both endpoints in parallel and deduplicate by tweet ID for full coverage. Untagged mentions typically outnumber tagged ones by 1.5x to 3x.

What's the rate limit on the Twitter mentions API?

On the official X API, mention endpoints have 15-minute rolling-window rate limits that vary by tier and authentication context. Rate limits apply specifically to recent search, filtered stream, user timelines, and mention timelines, with HTTP 429 returned on breach. On Sorsa, the limit is 20 requests per second across all endpoints with no 15-minute windows or monthly quotas.

How far back can I pull Twitter mentions?

The official X API's mentions endpoint returns up to ~800 of the most recent mentions per user via the standard endpoint, with full-archive access requiring Enterprise tier. Sorsa's /mentions supports since_date and until_date parameters reaching back through the full public X archive (2006-present).

Can I track mentions of multiple accounts at once?

Both APIs require separate requests per handle - there's no built-in multi-handle batch endpoint for mentions specifically. The standard pattern is a loop: iterate over your watchlist, call /mentions for each handle, deduplicate, merge. With Sorsa's flat rate, this scales linearly; on the official API, each handle multiplies your cost.

How do I export Twitter mentions to a CSV?

Pull mentions paginated through next_cursor, flatten each tweet object plus its embedded user profile into a single row, and write to CSV. See the exporting mentions section above for a complete script. Most analysts then load the CSV into Excel, Sheets, or a BI tool for sentiment classification and time-series analysis.

Can I use Twitter mention data for sentiment analysis?

Yes - this is one of the most common downstream use cases. Pull mentions to a CSV, run them through a sentiment classifier (a small Hugging Face model like cardiffnlp/twitter-roberta-base-sentiment-latest works well), and aggregate by day or campaign. The Twitter sentiment analysis guide covers the full pipeline.

Does the mentions API return private tweets?

No. Both the official X API and Sorsa expose only public X data. If a user has set their account to protected, their tweets don't appear in mention responses for anyone outside their follower list. This is a platform-level restriction, not an API limitation.

Getting started

The fastest path to your first mention query is the Sorsa playground: pick the /mentions endpoint from the sidebar, plug in a handle, and see the JSON response in your browser. No code, no API key for casual testing.

Once you're ready to build, grab an API key and start with the quickstart guide. The Starter plan ($49/month, 10,000 requests) handles most small-to-medium brand monitoring workloads comfortably. The migration from official X API guide covers the parameter mapping if you're moving existing code.

If you need to combine mentions with sentiment, follower extraction, or competitive analytics, the rest of the API reference covers 38 endpoints across users, tweets, search, lists, and communities.

About the author: Daniel Kolbassen is a data engineer and API infrastructure consultant with 12+ years of experience building data pipelines around social media platforms. He has worked with the Twitter/X API since the v1.1 era and has helped over 40 companies restructure their data infrastructure after the 2023 pricing overhaul. He writes about APIs, scraping, and social data engineering at api.sorsa.io/blog/daniel-kolbassen.

Last verified: May 17, 2026. Pricing and rate limits checked against the official X API documentation and Sorsa's pricing page.