Twitter 互动 API：获取回复、引用与转发用户（2026）

作者：Sorsa 编辑部

更新于 2026 年 7 月 6 日：新增 100 次免费请求的起步选项，把价格改用每千批量费率表述，把节省数字统一为最高 50 倍，收紧了内部链接，并对照线上 API 重新核实了每个接口。

核心要点： Twitter 互动 API 返回一条推文的点赞、回复、引用和转发计数背后的人和内容。官方 X API 把回复限制在一次七天的会话搜索，把转发用户封顶在 100。第三方 REST 接口按推文 URL 取回回复、引用和转发用户资料，带游标分页，不限年代。

一个点赞数是一个数字。一条回复是一个人、一个观点，有时是一个你的客服团队该回答的问题。一条推文底部的聚合计数是摘要；它们下面的互动才是真正的数据。

本指南把那份数据挖出来。你会取回一条推文完整的指标快照，再钻进那三种背后有人或文本的互动类型：评论（回复）、引用推文和转发用户。示例用 Sorsa API 这个 Twitter/X API 替代服务商，因为官方 X API 的互动产品被关在企业客户之后，而公开的绕过方案（一次过滤的会话搜索）只能查到最近七天。Sorsa 为任意年代的任意公开推文提供直接的评论、引用和转发用户接口，藏在一个 API 密钥后面，所有套餐统一 20 次/秒，在读密集型工作上最多可比官方 X API 的按资源定价便宜 50 倍。没有开发者账号审批，也没有 OAuth 流程：粘一个密钥就拉。

我们开发并运营 Sorsa，自 2022 年起累计处理请求超 50 亿次。下面的模式来自真实工作，从把团队从官方 API 迁移过来，到品牌监测作战室、规模化活动核验，以及学术对话研究。每个代码示例都用朴素的 requests，你可以直接粘进任意 Python 项目，不用封装库。

目录

1. 什么算推文互动？
2. 为什么从官方 X API 拿互动数据很难？
3. 官方 X API 与专用 Twitter 互动 API
4. 哪种互动类型信息量最大？
5. 如何获取一条推文的互动指标？
6. 如何获取一条推文的全部回复？
7. 如何获取一条推文的引用推文？
8. 如何查看谁转发了一条推文？
9. 为一条推文构建完整的互动报告
10. 跨多条推文对比互动
11. 规模化的互动抽取要花多少钱？
12. 如何核实某个特定用户是否互动过？
13. 导出互动数据
14. 实战：为一次上线作战室做回复抽取
15. 常见问题
16. 如何开始

什么算推文互动？ {#what-counts-as-tweet-engagement}

推文互动涵盖五种不同的动作，每种在 API 上暴露的方式都不同。点赞和浏览只作为计数暴露。回复和引用推文返回带文本、作者和指标的完整推文对象。转发返回放大了这条推文的用户资料，没有单独的文本，因为一次转发就是纯粹的再分发。

书签数也作为推文上的一个数字存在，但加书签的人是私密的。点赞过去会暴露点赞者信息流；X 在 2024 年 6 月对所有用户把点赞设为私密。真正有意思的工作发生在那三个你能触达底层人和文本的地方：回复、引用和转发用户。本指南剩下的部分聚焦这三类。

为什么从官方 X API 拿互动数据很难？ {#why-is-getting-engagement-data-from-the-official-x-api-hard}

从官方 X API 拿互动数据难，是因为计数和底层数据住在不同的地方。聚合指标（点赞、转发、回复、引用、浏览）在付费访问下通过 v2 public_metrics 对象可得。但实际的回复、引用推文和转发用户列表受限：回复需要一次限于最近七天的会话搜索，转发用户封顶在 100，而专用的互动产品仅限企业。

所以计数是容易的部分。下面是你一旦想要计数之外的东西就会撞上的三个障碍，按痛苦程度递增排列。

障碍 1：互动 API 仅限企业。 X 的互动 API 每次请求为最多 250 条推文返回 15 个以上的表现指标（展示量、互动、喜欢、转发、引用、回复、视频观看）。但在你能调用它、甚至调用公开的 /totals 接口之前，必须先为你的应用启用访问，而这个审批走企业销售，定价每月数千美元。对多数团队来说这条路根本走不通，而且即便走通，返回的也是指标，不是回复和引用本身。

障碍 2：拿实际回复要靠会话搜索这个绕过方案。 公开 X API 里没有 /tweets/:id/replies 接口。要采集回复，你得用 conversation_id:<tweet_id> 查询近期搜索，再按 replied_to 引用过滤。这管用，但有两个硬性限制：近期搜索只能查最近七天，而按量付费的速率限制很紧。全量存档搜索是通往更旧回复的唯一路线，但它和 Enterprise 访问、以及 X 在 2026 年对新注册关闭的遗留档位捆绑，所以对一条超过一周的推文，没有全量存档你就拿不到回复。这些限制的背景，见 2026 年 Twitter API 速率限制。

障碍 3：retweeted-by 接口被封顶且限速。 GET /2/tweets/:id/retweeted_by 存在，但顶多返回前 100 个转发用户，还被限在约每 15 分钟 75 次请求。对一条有数千转发的爆款推文，你只能拿到一个样本，仅此而已。专用的引用推文查询接口也每页封顶在 100，且限速。

三者的共同规律：计数便宜，底层数据被门禁、限时或封顶。这种定价背后更深的原因，见官方 X API 为何如此昂贵。

官方 X API 与专用 Twitter 互动 API {#official-x-api-vs-a-dedicated-twitter-engagement-api}

真正的差别在计费单位和触及范围。官方 X API 按抓取的资源计费，把底层的回复、引用和转发用户关在时间窗口、上限和企业访问之后。专用的第三方互动 API 按请求计费，按推文 URL 直接返回完整对象，对任意公开推文都有效，不限年代。

下表两侧都用真实数字，也包括我们真实的局限。Sorsa 只读：不发帖、不点赞、不关注、不发私信，所以任何写工作流仍归官方 API。

如果你只需要读寥寥几个聚合计数、而且已经在官方 API 上跑，public_metrics 在低量下就够。但一旦你要在规模上、或对超过一周的推文，拿回复、引用或转发用户资料本身，按资源的账单和上限就不再是偶发的了。这正是按请求计费的互动 API 成为可靠、完整选项的地带，也是我们为读密集型互动工作推荐 Sorsa 的原因。两侧完整定价在 Sorsa 定价页面和我们的 2026 年 Twitter API 价格详解里。

哪种互动类型信息量最大？ {#which-engagement-type-tells-you-the-most}

不是所有互动都一样有信息量。转发承载的信号最少：一次转发是一次没有评论的点击，衡量触达有用，但对理解“为什么”很弱。回复是中等信号，满是文本，但也满是噪音。引用推文承载最多，因为一次引用要费力：用户加了自己的框定，还把它广播给自己的受众。

转发的信号密度最低。 用户没解释为什么分享。你只学到一件事：这个人决定让自己的受众看到这个。对触达有用，对推理很单薄。

评论是中等信号。 回复含文本，也就意味着情感、问题、反对和纠正。它们同时也是低质“沙发”、垃圾和路过式批评的所在。量高、平均质量更低。

引用推文的信号密度最高。 一条引用的文本通常有实质：一个背书、一个批评、一个反论、一句“这话打脸了”。对公关、竞品情报和内容分析，引用是真正对话发生的地方，也是一条推文可能朝意外方向传播的地方，因为每条引用都是引用者信息流里一条新的顶层帖子。

我们构建互动看板时，做定性分析给引用推文的权重远高于评论和转发。确切比例不重要；要点是量和重要性在这三种类型上朝相反方向走。

如何获取一条推文的互动指标？ {#how-do-you-get-a-tweets-engagement-metrics}

一条推文的互动指标（点赞、转发、回复、引用、浏览、书签）来自一次推文查询调用，返回带这些计数的推文对象。聚合数字是最便宜的数据；更深的工作从你想要它们背后的人和文本时开始。先拿快照，再往里钻。

推文数据接口返回完整的推文对象、含作者；关于读取和对比这些数字的更多内容，见推文指标 API 指南。

import requests

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
HEADERS = {"ApiKey": API_KEY, "Content-Type": "application/json"}


def get_tweet(tweet_link: str) -> dict:
    resp = requests.post(
        f"{BASE}/tweet-info",
        headers=HEADERS,
        json={"tweet_link": tweet_link},
    )
    resp.raise_for_status()
    return resp.json()


tweet = get_tweet("https://x.com/elonmusk/status/1234567890")

print(f"Author:    @{tweet['user']['username']}")
print(f"Text:      {tweet['full_text'][:100]}")
print(f"Likes:     {tweet.get('likes_count', 0):,}")
print(f"Retweets:  {tweet.get('retweet_count', 0):,}")
print(f"Quotes:    {tweet.get('quote_count', 0):,}")
print(f"Replies:   {tweet.get('reply_count', 0):,}")
print(f"Views:     {tweet.get('view_count', 0):,}")
print(f"Bookmarks: {tweet.get('bookmark_count', 0):,}")

想一次拿许多推文的指标，用批量推文接口，每次请求最多接收 100 个推文 ID，只算一次调用。在 Pro 套餐上，这把单条推文成本降到约 $0.00002，分析数千条帖子时这一点很关键。

如何获取一条推文的全部回复？ {#how-do-you-get-all-the-replies-to-a-tweet}

一条推文的回复，通过翻页遍历那条推文下的评论话题串取回。官方 X API 没有回复接口，所以回复来自一次限于最近七天的会话搜索。专用的评论接口则为任意公开推文一页页返回完整的回复对象（文本、作者、指标），不限年代。

推文评论接口每页返回最多 20 条回复，接受 Relevance、Recency 或 Likes 的 order_by。在 next_cursor 上循环，把每条回复拉下来。

def get_comments(tweet_link, order="Relevance", max_pages=None):
    comments, cursor, pages = [], None, 0
    while True:
        payload = {"tweet_link": tweet_link, "order_by": order}
        if cursor:
            payload["next_cursor"] = cursor
        data = requests.post(f"{BASE}/comments", headers=HEADERS, json=payload).json()
        comments.extend(data.get("tweets", []))
        cursor = data.get("next_cursor")
        pages += 1
        if not cursor or (max_pages and pages >= max_pages):
            break
    return comments


replies = get_comments("https://x.com/user/status/123", order="Likes", max_pages=10)
print(f"Pulled {len(replies)} replies")

你能用回复数据做什么

每条回复都是一个完整的推文对象：文本、互动指标和作者资料。这解锁了几个模式：

• 情感和意图分类。 把回复文本过一遍情感模型或 LLM，把赞美、抱怨和问题分开。Twitter 舆情分析指南走了一遍“采集加分类”的管道。
• 客服分流。 过滤含问号或已知意图短语的回复，路由到客服队列。
• 网红浮现。 按 followers_count 给回复者排序，找出哪些知名账号在话题串里互动了。
• 垃圾过滤。 分析之前，丢掉来自最近一周创建、粉丝接近零的账号的回复；同样的启发式在粉丝关系图层面驱动虚假和机器人账号审计。

如何获取一条推文的引用推文？ {#how-do-you-get-the-quote-tweets-for-a-tweet}

引用推文作为完整推文对象取回，因为一条引用是一条嵌入原文、并加上引用者自己评论的新帖子。官方 X API 提供一个每页封顶 100、且限速的引用推文查询。专用的引用接口不带那个上限翻页，对任意年代的推文都有效。

引用推文接口每页返回最多 20 条引用；用 next_cursor 翻页。

def get_quotes(tweet_link, max_pages=None):
    quotes, cursor, pages = [], None, 0
    while True:
        payload = {"tweet_link": tweet_link}
        if cursor:
            payload["next_cursor"] = cursor
        data = requests.post(f"{BASE}/quotes", headers=HEADERS, json=payload).json()
        quotes.extend(data.get("tweets", []))
        cursor = data.get("next_cursor")
        pages += 1
        if not cursor or (max_pages and pages >= max_pages):
            break
    return quotes

分析引用推文的触达和语气

因为每条引用都带着作者的粉丝数和自己的文本，你可以按它们触达的受众给引用排名，再读一读排在前面的框定：

quotes = get_quotes("https://x.com/user/status/123", max_pages=10)

top = sorted(
    quotes,
    key=lambda q: q.get("user", {}).get("followers_count", 0),
    reverse=True,
)[:10]

for q in top:
    u = q["user"]
    print(f"@{u['username']} ({u.get('followers_count', 0):,} followers): {q['full_text'][:90]}")

对品牌监测，这是对的起点。一条来自 20 万粉丝记者或一位竞品高管的引用，正是那种该触发 Slack 告警的信号。一个常见做法是设一个阈值：引用者粉丝数超过 5 万，或引用者在一份精选行业名单上。命中的引用被路由进一个审查频道，用于实时监测工作流。

如何查看谁转发了一条推文？ {#how-do-you-see-who-retweeted-a-tweet}

一条推文的转发用户作为用户资料返回，因为一次转发没有独立的文本。官方 X API 把 retweeted_by 每条推文封顶在 100 个用户，并限在约每 15 分钟 75 次请求，所以对爆款推文你永远只看到一个样本。专用的转发用户接口越过 100 翻页，返回完整资料而不是裸 ID。

转发用户列表接口返回用户资料、最新在前，带 next_cursor 用于下一页。

def get_retweeters(tweet_link, max_pages=None):
    users, cursor, pages = [], None, 0
    while True:
        payload = {"tweet_link": tweet_link}
        if cursor:
            payload["next_cursor"] = cursor
        data = requests.post(f"{BASE}/retweeters", headers=HEADERS, json=payload).json()
        users.extend(data.get("users", []))
        cursor = data.get("next_cursor")
        pages += 1
        if not cursor or (max_pages and pages >= max_pages):
            break
    return users

从转发用户做受众分析

转发用户是刻画谁在放大一个账号最干净的方式。每一项都是完整的用户对象，所以你可以概括分享了一条推文的受众：

retweeters = get_retweeters("https://x.com/user/status/123", max_pages=20)

verified = [u for u in retweeters if u.get("verified")]
big = [u for u in retweeters if u.get("followers_count", 0) > 10_000]

print(f"{len(retweeters)} retweeters, {len(verified)} verified, {len(big)} with 10k+ followers")

想把同样的资料推得更远（地理、账号年龄、粉丝重叠），就把它和完整的粉丝关系图接口配合起来。

为一条推文构建完整的互动报告 {#building-a-full-engagement-report-for-one-tweet}

一份完整的互动报告，把一个指标快照和每种互动类型的一个样本结合起来，让一条推文的触达和反应落进一个对象。先拉计数，再拉回复、引用和转发用户，最后一起概括。

def engagement_report(tweet_link):
    tweet = get_tweet(tweet_link)
    comments = get_comments(tweet_link, max_pages=5)
    quotes = get_quotes(tweet_link, max_pages=5)
    retweeters = get_retweeters(tweet_link, max_pages=5)

    print(f"Tweet by @{tweet['user']['username']}")
    print(f"  likes={tweet.get('likes_count', 0):,}  "
          f"retweets={tweet.get('retweet_count', 0):,}  "
          f"quotes={tweet.get('quote_count', 0):,}  "
          f"replies={tweet.get('reply_count', 0):,}")
    print(f"Sampled {len(comments)} replies, {len(quotes)} quotes, "
          f"{len(retweeters)} retweeters")

    top_quotes = sorted(
        quotes,
        key=lambda q: q.get("user", {}).get("followers_count", 0),
        reverse=True,
    )[:5]
    for q in top_quotes:
        u = q["user"]
        print(f"  quote @{u['username']} ({u.get('followers_count', 0):,}): {q['full_text'][:70]}")

    return {
        "tweet": tweet,
        "comments": comments,
        "quotes": quotes,
        "retweeters": retweeters,
    }

每种五页只是一个样本，不是完整话题串。提高 max_pages 或去掉它就能翻完一切。在一个固定套餐上这是一个预算选择，不是一场速率限制之争：每一页都是对着同样的 20 次/秒上限发出的一次请求。

跨多条推文对比互动 {#comparing-engagement-across-multiple-tweets}

跨推文对比互动，用一次批量指标调用最高效：一次请求返回多达 100 条推文的计数，你在内存里推导比率。有用的发现很少是哪条推文在原始互动上赢，而是哪条推文的互动是不同形状的。

def get_metrics_bulk(tweet_links):
    data = requests.post(
        f"{BASE}/tweet-info-bulk",
        headers=HEADERS,
        json={"tweet_links": tweet_links},
    ).json()
    return data.get("tweets", [])


def compare_tweets(tweet_links):
    rows = []
    for t in get_metrics_bulk(tweet_links):
        likes = t.get("likes_count", 0) or 1
        rows.append({
            "id": t["id"],
            "likes": t.get("likes_count", 0),
            "replies": t.get("reply_count", 0),
            "quotes": t.get("quote_count", 0),
            "retweets": t.get("retweet_count", 0),
            "reply_to_like": round(t.get("reply_count", 0) / likes, 3),
            "quote_to_like": round(t.get("quote_count", 0) / likes, 3),
        })
    return sorted(rows, key=lambda r: r["reply_to_like"], reverse=True)

回复对点赞比高的推文在引发对话。引用对点赞比高，往往标志某样有争议的东西：对可见度好，有时对品牌坏。转发对回复比高是广播内容，讨喜可分享，但不引讨论。这些比率比任何单一计数都更能告诉你内容策略。

规模化的互动抽取要花多少钱？ {#what-does-engagement-extraction-cost-at-scale}

互动抽取很快就会膨胀：一条爆款推文可能带着 5 万条回复，而审计一个品牌的完整时间线能跑到数万次调用。有两件事让这在按请求计费的套餐上保持可负担：每个接口无论返回什么都算一次请求，而一次批量调用覆盖多达 100 条推文。

在 Pro 套餐上你每月 $199 拿到 10 万次请求，当你倚重批量接口时足够数百万条推文，因为一次多达 100 条推文的批量调用只算一次请求。官方 X API 是另一种形态：按量付费账号每月上限 200 万次帖子读取，按帖子读取 $0.005 加作者资料 $0.010 计费。所以一个读密集型互动负载既撞进一道硬性上限，又撞上一张快速攀升的账单。按请求计费既没有按资源收费，也没有 200 万上限。

统一的 20 次/秒适用于每个 Sorsa 接口、每个套餐。没有按接口的窗口、没有 15 分钟重置、没有意外掉线。撞上限制你会拿到一个 429；等一秒再重试。做一次深度审计（比如翻页遍历 5 万条回复）时，你用 50 毫秒的请求间隔、或一个小信号量来维持节奏，更高的限制可按需提供。

如何核实某个特定用户是否互动过？ {#how-do-you-verify-a-specific-user-engaged}

核实单个用户是否互动，是一个和“列出所有互动过的人”不同的问题。翻页遍历每个转发用户去找一个用户名是在浪费调用。专用的核验接口一次请求返回一个是/否，是抽奖检查、活动合规和大使计划的对的工具。

对规模化的抽奖和活动核验，三个接口回答常见情况，不管存在多少评论、引用或转发，每个都只用一次请求：

• /check-comment：这个用户回复了这条推文吗？
• /check-quoted：这个用户引用了这条推文吗？
• /check-retweet：这个用户转发了这条推文吗？

def did_user_comment(tweet_link, username):
    resp = requests.get(
        f"{BASE}/check-comment",
        headers=HEADERS,
        params={"tweet_link": tweet_link, "username": username},
    )
    return resp.json().get("commented", False)

对一个有 2,000 名参与者、三个必需动作的活动，那是 6,000 次调用，稳稳落在 Starter 套餐内。完整模式，包括关注检查，在我们的 Twitter 互动核验指南里。

导出互动数据 {#exporting-engagement-data}

互动接口返回 JSON，但多数分析发生在电子表格、数据框或数据库里。下面是一个面向回复的极简 CSV 导出器（也可复用于引用，同样是推文对象），让你快速拿到一个可用文件。

import csv


def export_comments_csv(comments, path="comments.csv"):
    fields = [
        "comment_id", "created_at", "full_text",
        "likes", "retweets", "reply_count",
        "author_username", "author_followers", "author_verified",
    ]
    with open(path, "w", newline="", encoding="utf-8") as f:
        writer = csv.DictWriter(f, fieldnames=fields)
        writer.writeheader()
        for c in comments:
            u = c.get("user", {})
            writer.writerow({
                "comment_id": c["id"],
                "created_at": c["created_at"],
                "full_text": c["full_text"],
                "likes": c.get("likes_count", 0),
                "retweets": c.get("retweet_count", 0),
                "reply_count": c.get("reply_count", 0),
                "author_username": u.get("username", ""),
                "author_followers": u.get("followers_count", 0),
                "author_verified": u.get("verified", False),
            })

对转发用户，把字段换成用户属性（username、display_name、followers_count、verified、created_at）。任务更大时，改为写入数据库：一个用 jsonb 列存原始载荷、外加几个索引列（tweet_id、author_id、created_at、likes_count）的 Postgres，能舒服地处理数千万行。如果你要把互动数据和其他社交信号按时间连接，历史 Twitter 数据指南讲了存档模式。

实战：为一次上线作战室做回复抽取 {#in-practice-reply-extraction-for-a-launch-war-room}

一个约 12 人的社交分析团队找到我们时，正为消费品牌跑上线作战室。他们的痛点是产品上线期间抽取客户推文下的回复，也就是社媒聆听的实时前沿。官方会话搜索只能查七天，所以对一次超过一周的上线做任何回顾都不可能，而实时上线期间的按资源计费让每日花费难以预测。

他们把回复、引用和转发用户拉取，迁到了固定套餐上的三次接口调用。两件事变了。可触达的历史从七天变成完整的公开存档，所以上线后的回顾不再是死路。而因为 Sorsa 按请求、而不是按资源计费，他们账单的读取部分大幅下降。在这类体量的读密集型工作上，按请求计费相对按资源计费最多可便宜 50 倍。这个胜利不是什么巧妙把戏，而是去掉了那个时间窗口和那张按条目的计价表。

常见问题 {#frequently-asked-questions}

能用 Twitter API 获取一条推文的全部回复吗？

用官方 X API 不能直接拿，因为它没有回复接口。受支持的绕过方案是一次对 conversation_id 的近期搜索查询，限于最近七天，除非你持有 Enterprise 全量存档访问。Sorsa 这类第三方 API 提供一个直接的评论接口，为任意公开推文带游标分页返回回复，不管推文年代。

转发和引用推文有什么区别？

一次转发把原推文原样再分发，没有附加文本，所以 API 只返回转发用户的资料。一条引用推文是一条嵌入原文、并加上引用者自己评论的新推文，所以它作为一个带自己文本、互动计数和作者的完整推文对象返回。做分析时，引用比转发有信息量得多。

如何查看谁转发了一条推文？

官方 X API 的 retweeted_by 接口返回转发用户，但把结果每条推文封顶在 100 个用户，并把调用限在约每 15 分钟 75 次，所以对爆款推文你只拿到一个样本。Sorsa 的转发用户接口用 next_cursor 越过那个上限翻页，返回完整用户资料，而不只是数字 ID。

X API 显示一条推文的评论吗？

官方 X API 没有“一条推文的评论”接口。回复只能通过用 conversation_id 的搜索接口触达，在按量付费访问下只能查最近七天。这让很多来自其他社交平台的开发者意外，在那些平台上，获取一条帖子的评论是一等操作。

API 每次请求能返回多少条回复？

Sorsa 的评论、引用和转发用户接口每页返回最多 20 条结果，而通过 next_cursor 的分页无上界，所以你可以在一个循环里获取任意年代推文的每一条回复。官方 X API 的近期搜索每页返回最多 100 条结果，但受请求速率限制和七天窗口约束。

能获取旧推文的互动数据吗？

用 Sorsa，能：评论、引用和转发用户接口对任意公开推文都有效，不限年代。用官方 X API，回复只对最近七天发布的推文可取回，除非你有 Enterprise 全量存档搜索，那需要审批和可观的成本。旧推文上的聚合计数无论哪种方式都仍可得。

有免费获取推文互动数据的方式吗？

官方 X API 在 2026 年没有免费额度，而按量付费模型从第一次调用起就收费，所以读取互动数据（帖子加作者资料）累加得很快。Sorsa 注册即送 100 次免费请求：无需绑卡，永不过期，覆盖全部 40 个接口，足够在投入套餐之前对真实推文拉取回复、引用和转发用户。Sorsa 的 Playground 也能从浏览器运行这些接口，所以你可以在写任何代码之前先看数据。

如何从 API 数据计算互动率？

互动率通常是（点赞 + 回复 + 转发 + 引用）除以展示量，或在拿不到展示量时除以粉丝数。推文对象上的 view_count 字段为 2022 年 12 月以来的帖子提供展示量。想不写代码跨一个账号的近期推文算它，用免费的互动率计算器。

如何开始 {#getting-started}

想在你自己的推文上试试：

1. 注册，约三分钟拿一个 API 密钥，无需开发者账号审批。注册即送 100 次免费请求：无需绑卡，永不过期，覆盖全部 40 个接口，走批量最多可覆盖 1 万条推文或 2 万份用户资料。付费用量在批量基础上仍然便宜，每 1,000 条推文 $0.02、每 1,000 份用户资料 $0.01 起，每个套餐都以统一 20 次/秒包含所有接口。
2. 在在线试用工具 Playground 里不写代码测试接口，或在 Sorsa API 文档里读完整规格。
3. 把本指南里的代码放进一个 Python 脚本、换进你的推文 URL、运行。

如果你要把一条现有数据管道从官方 X API 迁移过来，迁移指南逐接口映射了请求变化。用量超出所列套餐时，联系销售谈一个定制速率限制。欢迎在 Discord 上或通过 contacts@sorsa.io 提问。

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

本指南由 Sorsa 编辑团队撰写和核实，最后于 2026 年 7 月评审。内容取材于我们自 2022 年起在生产环境构建并运营 Twitter/X API 替代方案的经验、对照线上 API 测试这里描述的接口，以及当前的公开文档：接口行为和限制取自 Sorsa API 文档，互动 API 和 retweeted-by 接口取自官方 X 开发者文档。官方 X API 成本数字对照 X 截至 2026 年 4 月更新公布的按资源定价核查；X 的访问模型和平台历史细节（无免费额度、全量存档搜索现仅限 Enterprise、2022 年 12 月起的公开浏览量、2024 年 6 月起的平台级私密点赞）对照当前报道和 X 的文档核实；接口名称、参数和响应字段对照线上 Sorsa API 重新核实。团队的更多信息见我们的关于页面。