作者：Sorsa 编辑部

更新于 2026 年 7 月 8 日：把按请求计费的成本改用每千费率表述、新增 100 次免费请求的起步选项，并刷新了官方 X API 的 2026 年读取定价。

核心要点： Twitter 提及 API 把标记某用户名的公开帖子作为结构化 JSON 返回，带互动指标和作者资料。官方 X API 暴露 GET /2/users/{id}/mentions，按帖子读取计费，要求 OAuth 和一个数字用户 ID。第三方 API 从一个用户名、用一个密钥返回同样的数据，并内置日期和互动过滤。

如果你在 2026 年做提及追踪，Sorsa API 这个 Twitter/X API 替代服务商，去掉了让官方接口既贵又别扭的摩擦。你按用户名查询 /mentions 接口、不用先查用户 ID，把 min_likes、min_retweets 和 since_date 作为一等过滤参数传入，每条响应里还免费带完整作者资料。定价按请求计费、价格固定，不按帖子读取算：批量接口从每 1,000 条推文 $0.02 起。因为 /mentions 响应把作者资料随每条帖子一起返回，你从不为官方 API 在每帖 $0.005 读取之上另加的那次单独作者读取付费。加信用卡之前可以用 100 次免费请求先试，没有开发者账号审批队列，速率限制是所有套餐统一 20 次/秒。

品牌提及监测过去是社交工具上的一个功能勾选项，到 2026 年成了一个 API 问题。营销团队想要供 BI 看板用的干净 JSON，客服团队想要一个触发 Slack 提醒的轮询循环，数据团队想要一份上季度引用某品牌的帖子 CSV 用于情感建模。本指南讲清几件事：这些接口是什么、如何对比、今年花多少钱、漏掉了什么（未打标签提及问题）。最后讲如何搭建不会一周就烧光额度的生产级监测。代码里我们用 Sorsa 的 /mentions 接口，因为它是我们自己开发和运营的，参数也干净地对应到下面的工作流；但这些模式适用于任何服务商。

目录

什么算一次 Twitter 提及 {#what-counts-as-a-twitter-mention}

在 X 上，一次提及是任何在正文里含 @yourhandle 的公开帖子。回复算，引用帖算，标记该用户名的独立帖子也算。提及会出现在平台的通知（Notifications）标签里，但那一面被限速、暴露不出有用的互动指标，也不提供编程接口。

提及 API 把那条流变成结构化数据：一个帖子对象的 JSON 数组，每个都带文本、时间戳、互动指标（点赞、转发、回复、浏览）和完整作者资料。你可以过滤、分页、去重，再把数据路由到任何地方，无论是数据库、Slack 频道、情感分类器还是 BI 看板。

用例落进五个清晰的类别：

  1. 品牌声誉监测。 抓住每一场关于产品的公开对话，在负面情绪扩散之前把它路由给公关。
  2. 客户支持分诊。 检测以帖子而非邮件到达的支持请求，推进 Zendesk、Intercom 或 Linear。
  3. 活动衡量。 一次发布之后，数提及、汇总互动、识别头部声音并出报告。
  4. 竞品情报。 对竞品用户名跑同样的分析，看谁在获得关注、人们在说什么。
  5. 网红和公关追踪。 在一条帖子驱动计划外流量之前，检测某个高粉丝账号何时提及一个品牌。

把这些串起来的是量和时效。你需要很多提及、需要它们快、也需要把信号从噪音里分出来，这就是互动指标要紧的原因：它们是你的噪音过滤器。这也排除了手动核查，以及任何不批量暴露互动数据的来源。

为什么通知和手动搜索不够 {#why-notifications-and-manual-search-fall-short}

X 的通知系统只在有人用你的 @handle 时触发。业界社媒聆听研究一致发现，未打标签的引用占了品牌对话的多数，常被引用在 70% 左右。这和我们跨客户数据管道看到的情况一致。多数人在朴素的文字里直接打一个品牌名，不去查用户名，或者用话题标签，或者把名字拼错，而这些都不会产生一条通知。

通过 X 界面的手动搜索能处理小量，但只能取到近期结果、不批量暴露互动指标，也不契合任何自动化工作流。只要超出一个每周 50 次提及的爱好账号规模，你就需要 API。

2026 年通过 API 拉提及的两种方式 {#the-two-ways-to-pull-mentions-via-api-in-2026}

做程序化提及追踪，你有两个现实选项。

第一个是官方 X API v2，具体是 GET /2/users/{id}/mentions 接口：按量付费定价、OAuth 配置、只接受数字用户 ID。第二个是第三方 Twitter API 替代方案（比如 Sorsa）：固定月度套餐、一个 API 密钥、基于用户名的查询，以及内建进接口的过滤。两者都返回公开 X 数据。真正的差别归结为认证开销、查询体验、过滤能力，以及在你具体量级上的成本。

下面是并排对比，两侧都用真实数字，我们自己的局限也如实列出：

官方 X API 提及Sorsa /mentions
接口GET /2/users/{id}/mentionsPOST /v3/mentions
查询依据数字用户 ID（先解析用户名）直接用用户名
认证OAuth 2.0 + bearer 令牌、已批准开发者账号单个 API 密钥请求头、无审批
内建过滤无（仅 since_id、start_time 加窗）min_likes、min_retweets、min_replies、since_date、until_date、order
作者资料单独用户读取或 expansions含在每条响应里
每请求结果数最多 100最多约 20
定价模型按帖子读取固定月度请求
读取成本$0.005/帖（自有读取 $0.001）+ 单独作者读取按请求计费，每次调用约 20 条提及、含作者资料
速率限制15 分钟窗口，随档位而变所有套餐统一 20 次/秒
回溯约 800 条最近（全量存档 = Enterprise）完整公开存档（2006 至今）
写动作有（发帖、私信；关注/点赞/引用移到 Enterprise）无（只读）

官方接口每请求返回更多帖子（最多 100，Sorsa 每页约 20），这是官方接口领先的一根轴。但成本一进入画面，这个优势就不再决定性。在按请求计费的套餐上，请求数不按条计费，而内建过滤加用户名查询也省掉了官方路径强加给你的额外调用。

官方 X API：GET /2/users/{id}/mentions {#the-official-x-api-get-2-users-id-mentions}

官方接口返回按数字 ID 提及某用户的帖子。基础请求：

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

据此构建之前，有几件事要知道：

  • 你需要一个数字用户 ID，不是用户名。 给定 @yourbrand，你要先调用用户查找接口把它解析成一个 ID。这是你监测的每个用户名一次额外的、可计费的读取。
  • 认证走 OAuth。 你需要一个开发者账号、一个已批准项目和一个 bearer 令牌，带 tweet.read 和 users.read 作用域。
  • 默认响应很精简。 在我们对官方接口的实测里，一次裸调用只返回帖子 ID 和文本。互动指标、语言、媒体和作者资料每一样都要显式列参数：tweet.fields（供 created_at、public_metrics、lang、context_annotations、entities）、expansions（供 author_id、attachments.media_keys、referenced_tweets.id）、user.fields（供 username、name、verified、public_metrics），以及 media.fields。忘了这些，是我们在切换过来的代码里见到最常见的 bug。
  • 没有互动或日期过滤。 你能用 start_time、end_time、since_id 和 until_id 加窗，但没有 min_likes 或 min_retweets。要只保留 50 个赞以上的提及，你得把一切拉下来、在客户端过滤。
  • 每请求和回溯有上限。 max_results 每次调用接受 5 到 100，你用 pagination_token 分页。标准访问只能取到每个用户约最近 800 条提及；更早的历史需要 Enterprise 档位，所以这个接口是为近期监测、而不是深度存档而做的。

官方提及接口在 2026 年花多少钱

2026 年，X API 走按量付费，对新开发者没有免费额度，读取每帖 $0.005。提及这里有个小转折：按 2026 年 4 月的定价更新，“自有读取”（你自己的应用为你自己账号的帖子、提及、粉丝等发的请求）定价为每资源 $0.001。如果你以你正要拉提及的那个账号认证，读取就符合自有读取费率。如果你拉的是别的账号（一个竞品、一个公众人物、一个无关品牌），就付标准的每帖 $0.005。

直说：在官方 API 上监测你自己的品牌每 1 万条提及约 $10，监测竞品每 1 万条约 $50。还有一个每月 200 万次帖子读取的上限，突破上限需要 Enterprise。这个接口可靠、文档完备，只是在规模上变贵，尤其对竞品监测，而那正是自有读取折扣覆盖不到的情形。完整的成本结构，我们在 2026 年 Twitter API 定价和 Twitter API 为何这么贵里深挖过。

按请求计费的替代方案：Sorsa /mentions 接口 {#a-flat-rate-alternative-the-sorsa-mentions-endpoint}

Sorsa 的接口把官方路径上的那些摩擦点去掉了：基于用户名的查询、内建过滤和固定定价。

bash
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"
  }'

和官方路径的差别是实打实的：

  • 直接用用户名，无需 ID 查找。 传 "query": "AppleSupport"，而不是先解析到一个用户 ID。
  • 单请求头认证。 ApiKey: ... 取代 OAuth bearer 配置，也没有开发者账号审批。
  • 过滤是一等参数。 min_likes、min_retweets、min_replies、since_date、until_date 和 order（popular 或 latest）是真实参数，而不是你编进查询字符串的搜索操作符。
  • 每条响应里带完整作者资料。 不用记 expansions 或 user.fields。
  • 固定定价。 套餐是月度请求档位，一次调用算一次请求，不管返回多少条提及。成本固定、不按资源：批量接口从每 1,000 条推文 $0.02 起，搜索式的 /mentions 接口每次调用返回约 20 条提及，在 Pro 上折算为约每 1,000 条提及 $0.10 起。注册即送 100 次免费请求，无需绑卡。

响应结构：

json
{
  "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..."
}

每条提及在一条响应里就带着完整互动指标和完整作者资料返回，不用再发后续调用去补齐。完整参数集见提及接口参考。

提及对比搜索：已打标签和未打标签的覆盖 {#mentions-vs-search-tagged-and-untagged-coverage}

提及接口，不管哪家服务商，都只捕捉直接的 @handle 标签，捕捉不到不带 @ 就点名一个品牌的帖子，而那正是品牌对话的多数。要完整覆盖，你需要两个接口协同工作。

用提及接口做直接标签：查询更干净、内建互动过滤、监测循环更简单。用推文搜索接口做未打标签的品牌引用：把品牌名作为关键词传入（例如 "nike" -from:nike lang:en），把任何不用用户名就讨论该品牌的人都捞进来。Sorsa 的搜索推文接口支持完整的一套搜索操作符：精确短语、布尔逻辑、排除、语言和媒体过滤，以及地理。做生产监测时，两个并行跑，按帖子 ID 去重。并行查询的写法在下面的捕捉未打标签的提及里。

五个生产工作流 {#five-production-workflows}

下面这些是我们跨客户项目交付过、或见到别人交付过的模式。每个用一套不同的参数组合解决一个不同的问题。

1. 消费品牌的声誉看板

目标：只浮现有真实受众触达的提及，把机器人标签、垃圾和零互动噪音丢掉。

python
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):
    """拉按最低互动过滤的提及，按热度排序。"""
    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")

order: "popular" 加 min_likes: 100 的组合就是噪音过滤器。品牌较小就把阈值降到 5 或 10，财富 500 强品牌就推到 500。

2. 客户支持队列

目标：捕捉每一条提及，包括零互动的，因为每一条都可能是一位等待帮助的客户。

python
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]}")

生产环境里每 30 到 60 秒轮询一次，把打了标签的提及路由进工单系统。我们给一个 DTC 服饰客户搭过一个版本，他们的支持团队原本完全漏掉了基于帖子的问题；把打了标签的提及路由进队列后，浮现出邮件从来抓不到的相当一部分请求。

3. 活动衡量

目标：一次发布或营销推动之后，在一个特定窗口内量化量、独立声音和聚合互动。

python
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)

按日期加窗的拉取正是深度存档覆盖要紧的地方。公开存档回溯到 2006 年，所以你能对三年前的一次发布跑同样的分析来做对标。

4. 竞品情报

目标：跨多个竞品用户名做相同的分析，对比公开关注度。

python
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}")

每周跑一次，就有了一块轻量的竞品看板。把它和 Twitter 分析 API 接口结合能得到更完整的画面，或者看看团队怎么把这接进持续的竞品追踪。

5. 危机检测

目标：捕捉提及量的突然峰值，这可能预示一个公关问题。

python
import time
from collections import deque

WINDOW_MINUTES = 60
SPIKE_MULTIPLIER = 3.0

baseline = deque(maxlen=24)  # 过去 24 小时的每小时计数

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 和 send_alert 是应用特定的辅助函数。）要紧的是这个模式：维持一个滚动基线，在偏离时提醒。我们给一个对冲基金客户搭过一个更精细的版本，把提及峰值和情感评分结合起来，标记潜在的动市事件。端到端的做法，见实时 Twitter 监测。

捕捉未打标签的提及 {#catching-untagged-mentions}

提及接口只捕捉直接的 @handle 标签。要完整覆盖，就把品牌名当关键词并行查询一个搜索接口，再去重：

python
def full_coverage_mentions(handle, brand_name, since_date):
    """拉取已打标签和未打标签的提及，按帖子 ID 去重。"""
    seen_ids = set()
    all_mentions = []

    # 路径 1：直接的 @ 提及
    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)

    # 路径 2：未打标签的品牌名引用
    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

-from:{handle} 排除把品牌自己的帖子挡在结果之外，lang:en 按语言过滤（去掉它就能做多语言覆盖）。给每条提及标上来源，下游消费者就知道它是经由标签还是关键词进来的。以我们的经验，未打标签的提及在 B2C 品牌上主导量，在 B2B SaaS 上则和已打标签的大致持平。跳过这一步，你就漏掉了关于一个品牌的多数对话。通过 API 搜索推文的配套指南，讲了这条路径依赖的查询语法。

把提及导出为 CSV {#exporting-mentions-to-csv}

对在 Excel、Sheets 或 BI 工具里工作的分析师，你需要一个扁平化的文件。一次性导出：

python
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}")

到这里，情感分析只差一次分类器调用。Twitter 舆情分析指南讲了完整的管道。

用 Slack 或 Discord 做实时提醒 {#real-time-alerts-with-slack-or-discord}

基于轮询的提醒是准实时监测的实际基线。最小可行模式：

python
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)

生产环境里，把 last_seen_id 跨重启持久化（文件、Redis、数据库），给 429 加指数退避，并按关键词把不同类型的提及路由到不同频道。Sorsa 统一的 20 次/秒，远比任何合理的轮询循环所需的余量更宽。

提及追踪实际花多少钱 {#what-mention-monitoring-actually-costs}

这是服务商选择影响最大的地方。拿一个现实的负载算一算：每月 1 万条提及，分摊在你自己的品牌和三个竞品之间。下表官方 X API 读取费率截至 2026 年 7 月为当前值。

路径算式每月成本
官方 X API，仅自有品牌（自有读取）1 万次读取 × $0.001约 $10
官方 X API，竞品提及1 万次读取 × $0.005约 $50
官方 X API，3 个竞品各 1 万3 万次读取 × $0.005约 $150
Sorsa Starter（1 万次请求，约 20 万条提及）固定$49
Sorsa Pro（10 万次请求，约 200 万条提及）固定$199

Sorsa 自己的成本远在任一读取费率之下。按每千算，批量接口从每 1,000 条推文 $0.02 起，搜索式的 /mentions 接口在 Pro 上从约每 1,000 条提及 $0.10 起，两者都含作者资料。注册即送 100 次免费请求，可以在投入套餐之前把这一切验证一遍。

官方 API 在你只监测一个账号、而且是你自己的账号时还行。但只要涉及任何规模的多账号或竞品监测，账就很快对按量付费不利。每月 1 万条带作者资料的竞品提及，已经比一个覆盖约 20 万条的 Sorsa Starter 套餐更贵。还有可预测性问题。按量付费下，一次意外的提及峰值要花你钱；按请求计费下，则不会。这个差距就是我们把 Sorsa 定位为读密集型工作更优选项的原因：对带作者资料的竞品监测，它跑得最多可比官方 API 便宜 50 倍，而成本固定。

常见陷阱 {#common-pitfalls}

我们跨客户实现里见到的几个错误：

min_likes 设得太高、漏掉重要提及。 一个报告了关键 bug、只有 2 个赞的客户，比一个 500 个赞的梗更要紧。做支持用例时，把 min_likes 设为 0，高阈值留给声誉看板和趋势分析。

忘了分页。 单次请求返回约 20 条提及。如果一个品牌每天得到 200 条提及，一页只捕捉了对话的 10%。任何分析或导出都要循环 next_cursor，直到它为空。

把已打标签和未打标签的提及当作同一个数据集。 已打标签的提及偏向直接互动（支持请求、回复）；未打标签的提及偏向一般讨论和推荐。粗心地混起来，情感数字就会偏。

轮询太激进。 对一个每天 10 条提及的账号每秒轮询一次是在浪费请求。把间隔匹配到量：高流量品牌每 15 秒，较小账号每一到两分钟。速率限制是所有套餐统一 20 次/秒。

不跨重启持久化状态。 实时监测器会崩。如果不带检查点就重启，监测器要么重新处理旧提及（重复提醒），要么跳过缺口（漏掉提及）。把最后见到的 ID 存在某个耐久的地方。

只为监测一个竞品就认证到官方 API。 官方接口能拉任何公开账号的提及，但 $0.001 的自有读取费率只在你以那个同一账号认证时才适用。官方 API 上的竞品监测付全额的每帖 $0.005，除了换服务商之外没有别的绕法。

实战：监测一个品牌及其对手 {#in-practice-monitoring-a-brand-and-its-rivals}

一个约 15 人的中型分析团队，为消费品牌运营社交看板，在官方 API 的按资源定价让竞品监测撑不住之后找到我们。他们的负载对这一类很典型：一个自有品牌加三个竞品，每条提及都附作者资料和粉丝数、持续拉取。在官方 API 上，自有品牌读取符合 $0.001 的自有读取费率，但每条竞品提及按每帖 $0.005 计费，外加每个作者一次单独的用户读取，账单还随着他们无法预测的量攀升。把竞品流迁到按请求计费的替代方案后，这笔成本塌缩了超过一个数量级，因为同一次调用返回最多约 20 条含作者资料的提及、只算一次请求。对读密集型的竞品监测，Sorsa 跑得最多可比官方 API 便宜 50 倍，所以量越大，节省越成立。可预测性和那个头条数字一样要紧：竞品产品发布期间的一次峰值，不再变成一张意外账单。对主要工作就是品牌监测的团队，这个模式常见到我们干脆围绕它做了一个社媒聆听方案。

常见问题 {#faq}

Twitter（X）有提及 API 吗？

有。官方 X API v2 暴露 GET /2/users/{id}/mentions，返回按数字 ID 提及某个特定用户的帖子。该接口要求 OAuth 认证和一个已批准开发者账号，2026 年按量付费计费，每帖读取 $0.005；如果认证账号和被查询账号一致，走自有读取费率 $0.001。

能追踪不带 @ 标签的 Twitter 提及吗？

能，但不是通过提及接口。提及接口只捕捉用 @ 标记一个用户名的帖子。要捕捉未打标签的品牌引用，用把品牌名当关键词的推文搜索接口，再按帖子 ID 把两条流去重。业界社媒聆听研究发现，未打标签的提及占品牌对话的多数，常被引用在 70% 左右。

Twitter 提及 API 的速率限制是多少？

在官方 X API 上，提及时间线接口用 15 分钟滚动窗口限速，具体额度随访问档位和认证类型而变，超出时返回 HTTP 429。在 Sorsa 上，限制是所有接口和套餐统一 20 次/秒，没有 15 分钟窗口或每月帖子上限，还可按请求提高。

能回溯拉多久以前的 Twitter 提及？

官方 X API 的提及接口在标准访问上返回每个用户约最近 800 条提及，全量存档历史被 Enterprise 档位门控。Sorsa 的 /mentions 接口接受 since_date 和 until_date 参数，可回溯穿过完整的公开 X 存档，从 2006 年到现在。

能一次追踪多个账号的提及吗？

官方 X API 和 Sorsa 都不提供针对多个用户名提及的单个批量接口。所以标准做法是一个循环：遍历一份监测名单，逐个用户名调用提及接口，再去重合并。用 Sorsa 的按请求计费，这以一个固定月度成本线性扩展；在官方 API 上，每加一个用户名都会把你的按资源账单翻倍。

开发者在 2026 年怎样以高性价比访问 Twitter 提及数据？

多数团队现在用第三方 Twitter/X API，而不是付官方 API 的按资源读取费率。Sorsa API 就是这样一个选项：按用户名返回提及，内建互动和日期过滤，每条响应里包含完整作者资料，并收一个固定月度费率，而不按帖收费。注册即送 100 次免费请求（无需绑卡、覆盖全部 40 个接口），付费套餐则保持固定，不管每次调用返回多少条提及。

能把 Twitter 提及数据用于情感分析吗？

能，这是最常见的下游用途之一。把提及拉进一份 CSV，把每条帖子过一遍情感分类器（cardiffnlp/twitter-roberta-base-sentiment-latest 这类紧凑模型效果很好），再按日或按活动聚合。因为提及响应已经包含互动指标，你可以按触达给情感分数加权，而不是平等对待每条帖子。

提及 API 返回私密推文吗？

不。官方 X API 和 Sorsa 都只暴露公开 X 数据。如果一个账号被设为受保护，它的帖子不会出现在其粉丝之外任何人的提及响应里。这是 X 强制的平台级隐私限制，而不是某个特定 API 服务商的局限。

如何开始 {#getting-started}

看一条提及响应最快的方式是 Sorsa Playground：选 /mentions 接口、打一个用户名，无需密钥、无需代码就在浏览器里读 JSON。准备好构建时，创建 API 密钥并领取 100 次免费请求（无需绑卡、覆盖全部 40 个接口、永不过期），再跟着快速上手走。付费套餐保持固定，不管每次调用返回多少条提及；从官方 X API 迁移指南会在你搬移现有代码时映射那些参数。要把提及和情感、粉丝提取或竞品分析结合，API 参考覆盖了用户、推文、搜索、列表和社区共 40 个接口。如果统一 20 次/秒、即时且免审批的配置契合你的工作方式，Sorsa 就是我们会第一个推荐给你的 Twitter/X API 替代方案。

审校：Keksich（Sorsa 创始人，X API 研究者）

本指南取材于我们自己开发并运营 Twitter/X API 替代方案的经验、对照测试的线上 Sorsa 接口，以及官方 X API 关于提及时间线接口及其 2026 年定价的文档。接口名、参数和限制对照 Sorsa API 文档核查；两个 API 的读取价格反映 X API 的 2026 年 4 月按量付费更新和当前的 Sorsa 定价。谁在发布这个博客，见关于 Sorsa，有更正请联系团队。核验于 2026 年 7 月 8 日。