X Articles API：获取长文 X 帖子内容（2026）

作者：Sorsa 编辑部

更新于 2026 年 7 月 8 日：把文章取回定价重新表述为每 1,000 费率、加入了 100 次免费请求的入门额度，并把官方 X API 对比削减到文章访问能力。

要点 X Articles 是 X 上的长文帖子，容纳最多约 10 万个字符，带一张封面图和丰富格式。官方 X API 只暴露一个 t.co 包装，而不是正文。取回完整文本、封面图、发布日期和互动指标，需要一次专门的 REST 调用。

替代性 Twitter/X API 提供方 Sorsa API 用一个专门的 POST /v3/article 接口合上那个缺口，在单次请求里把完整文章对象作为 JSON 返回：正文文本、封面图、发布日期和每一个互动指标，没有 OAuth、没有应用审查，也没有无头浏览器。每次取回都是一次请求，从每 1,000 篇文章 $1.80 起，速率是所有套餐统一 20 次/秒。新密钥注册即送 100 次免费请求（无需绑卡），所以这个接口能在任何花费之前先测试。

自 X 在 2026 年 1 月向所有 Premium 订阅者开放 Articles 以来，更多记者、分析师和项目团队把长文内容原生发布在这里，而不是在 Medium 或 Substack 上。对任何构建监控或分析的人来说，玄机在于：官方 X API 从未围绕 Articles 对象设计，所以一次标准的推文查找只递回一个短链接，别无其他。本指南是一份用 X Articles API 工作的实际参考。内容包括：这个格式是什么、官方接口为何返回不了它，以及如何在一次 REST 调用里拉完整文章正文、元数据和指标。文中还附有用于检测、竞品对标和内容分析的可运行 Python。

目录

• 什么是 X Articles？
• 为什么官方 X API 不返回文章内容
• X Articles vs 长帖 vs 话题串
• 你何时需要对 X Articles 的编程访问
• 取回一篇 X Article：那个接口
• 检测一条帖子是否是一篇 X Article
• 对标竞品文章
• 用 NLP 分析文章内容
• 定价和速率限制
• 常见问题

什么是 X Articles？ {#what-are-x-articles}

X Articles 是 X（前身 Twitter）上一个原生长文发布格式，让符合条件的账号发布最多约 10 万个字符的格式化篇章，远超 280 字符的推文限制。每篇 Article 有一张封面图、一个标题、带小标题和列表的正文、嵌入媒体，和自己的发布日期，并出现在作者资料上一个专门的 Articles 标签下。

X 于 2024 年 3 月 8 日推出 Articles，最初供 Premium+ 订阅者和已认证组织。据 Engadget，上限落在约 10 万个字符，对比单独长帖功能的 2.5 万。在 2026 年 1 月 7 日，X 产品负责人 Nikita Bier 宣布这个功能扩展到所有 Premium 订阅者，结束 Premium+ 独占。Social Media Today 报道，X 把这次推动与一次性的 100 万美元奖金配对，奖励其 2026 年 1 月下旬支付期的最佳长文 Article；该奖对发布至少 1,000 词原创篇章的美国 Premium 用户开放，主要按已认证主页时间线展示量评判。

当你对着这个格式构建时有几个性质要紧：

• Articles 携带自己的互动对象，其模式与普通推文不同，尤其是更高的收藏率和更低的转推率。
• 链接一篇 Article 的公告帖仍是一条普通推文；文章正文在一个单独的对象里。
• Article 的发布日期不同于公告推文的 created_at。

为什么官方 X API 不返回文章内容 {#why-the-official-x-api-doesnt-return-article-content}

官方 X API 不暴露 Article 正文。当一个作者发布一篇 Article 时，X 创建一条链接到该文章的公告推文；一次标准推文查找只返回那条推文的文本，其中含一个 t.co 短链接，而不是文章内容。跟着那个链接，会重定向到 x.com/i/article/{id} 的一个渲染网页，而不是一个 JSON 接口，所以正文、封面图和发布日期通过正常的帖子读取调用仍不可及。

一次对公告推文的标准 v2 查找返回像这样的东西：

{
  "data": {
    "id": "1234567890",
    "text": "Just published a new piece on the state of crypto Twitter in 2026 https://t.co/XYZ123",
    "edit_history_tweet_ids": ["1234567890"]
  }
}

那个 t.co 链接就是全部载荷。没有正文、没有封面图、没有发布日期。

note_tweet 字段不解决这个。这个字段是为 2.5 万字符的长帖而加的，是另一个功能：一个单一文本块，没有格式、没有封面图、没有单独发布日期，上限也远在 Article 之下。读 note_tweet 给你的是长帖文本，从不是 Article 内容。

团队去拿的绕过方案全都涉及浏览器自动化：用一个已认证 cookie 驱动一个无头浏览器打开渲染的文章页、爬取 DOM。这对一次性任务撑得住，但作为生产环境的数据管道，就成了一项常驻税。你要跑一个浏览器集群、在 cookie 过期前轮换、处理挑战，并看着延迟从毫秒攀到秒。这正是把团队推去找一个 Twitter API 替代方案的缺口：数据是公开的，访问方式本应是一次 REST 调用，官方 API 却仍逼你去够一个浏览器。

具体到文章取回，实际的对比重点不在每次调用的价格，而在正文究竟是否可及。下表把一个暴露直接文章接口的只读 X 数据 API，与官方 X API 对比。

如果你需要发布 Articles 或写入 X，那是官方 API 的地盘，因为只读 X 数据 API 不发帖。要以固定、可预测的价格、不用一套爬取栈就拉到文章内容，一个直接文章接口是更简单的路。Sorsa API 是我们的产品，所以请把这张表当作厂商自己的对比，并在投入之前对着你自己的工作负载测试任何提供方。

X Articles vs 长帖 vs 话题串 {#x-articles-vs-long-posts-vs-threads}

X 有三种不同的长文机制，容易混淆。普通推文封顶在 280 字符。长帖（有时叫扩展帖）对 Premium 订阅者达 2.5 万字符，在 API 里作为 note_tweet 浮现。X Articles 是一个最多约 10 万字符的单独格式，带标题、粗体和斜体文本、列表、嵌入媒体、一张封面图，和一个专门的资料标签。

对任何构建监控的人来说，要点是：普通推文和长帖通过标准 API 带告诫可及，但 Article 正文不可及，所以需要一个专门的取回方法。

你何时需要对 X Articles 的编程访问 {#when-you-need-programmatic-access-to-x-articles}

每当长文正文本身就是数据时，你需要取回 Article 对象，而不只是它们的公告推文。常见情形有：竞争性内容情报、对特定作者的耐久归档、对干净长文文本的 NLP、对着普通推文的互动对标，以及媒体或记者监控；在后者里，Articles 是一等来源，而不是一个爬取的事后补救。

竞争性内容情报。 长文 Article 比一家公司的短推文流，远更清晰地揭示其信息策略，因为 Articles 是深思熟虑且结构化的。每周拉竞品 Articles 并做差分，是一个低投入、高信号的循环，能自然接入更广的竞品分析工作流。

归档和内容数据库。 如果你的团队依赖特定分析师、交易员或创始人，一份耐久的归档能在一条帖子被编辑、删除或隐藏时保护你。full_text、published_at 和作者字段，给了一个可搜索存储所需的一切；对较旧的材料，你能用历史推文取回扩展同样的做法。

NLP 训练和分析。 Articles 是平台上最干净的长文文本之一：书写、编辑并刻意结构化，这让它们比嘈杂的短推文流更适合情感分析和话题建模。更广的模式在我们的情感和话题分析指南里。

互动对标。 Articles 比推文偏向更高的收藏率和更低的转推率，所以拿它们去和普通帖子对标会扭曲数字。应单独拉 Article 对象，把它们当作独立的一类来分析，就像你会处理推文级分析那样。

记者和思想领袖监控。 随着 X 积极招揽写作者，记者更常发布到 Articles，所以一个媒体监控工具需要把 Article 摄入当作一手来源。要对来自一份观察列表的新 Articles 做亚分钟检测，架构和实时监测一致。

取回一篇 X Article：那个接口 {#fetching-an-x-article-the-endpoint}

通过一个 REST API 取回一篇 X Article 只需一次调用：把公告推文的 URL 或数字 ID 发给一个文章接口。响应把完整正文文本、预览片段、封面图 URL、发布日期和互动计数作为 JSON 返回。不涉及 OAuth 握手，也不涉及浏览器渲染；认证是请求头里的单个 API 密钥。

在 Sorsa 上，那个接口是 POST /v3/article。完整规格住在文章接口参考里。

请求

POST https://api.sorsa.io/v3/article
Content-Type: application/json
ApiKey: YOUR_API_KEY

{
  "tweet_link": "https://x.com/SorsaApp/status/1234567890"
}

tweet_link 字段接受完整的公告推文 URL 或只是数字推文 ID。

响应（200）

{
  "full_text": "this isn't a cosmetic rebrand. it's a response to how crypto twitter actually works in 2026...",
  "preview_text": "this isn't a cosmetic rebrand. it's a response to how crypto twitter actually works in 2026...",
  "cover_image_url": "https://pbs.twimg.com/media/G-t2hYTaIAAstc8.jpg",
  "published_at": "2026-01-15T16:24:02Z",
  "likes_count": 315,
  "retweet_count": 41,
  "reply_count": 80,
  "quote_count": 37,
  "bookmark_count": 38,
  "views_count": 36538,
  "author": {
    "id": "1934538036466810880",
    "username": "SorsaApp",
    "display_name": "Sorsa",
    "followers_count": 6050,
    "verified": false
  }
}

一个值得在数据管道边缘处理的字段名细节：文章响应用 views_count，标准推文对象却用 view_count。如果你把两者推过同样的代码，就把这个键规范化。完整映射在响应格式参考里。

快速上手

curl -X POST https://api.sorsa.io/v3/article \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"tweet_link": "https://x.com/SorsaApp/status/1234567890"}'

import requests

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

def get_article(tweet_link: str) -> dict:
    """按公告推文 URL 或 ID 取回单篇 X Article。"""
    resp = requests.post(
        f"{BASE_URL}/article",
        headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
        json={"tweet_link": tweet_link},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()


if __name__ == "__main__":
    article = get_article("https://x.com/SorsaApp/status/1234567890")
    print(f"Author:      @{article['author']['username']}")
    print(f"Published:   {article['published_at']}")
    print(f"Views:       {article['views_count']:,}")
    print(f"Body length: {len(article['full_text']):,} chars")

没有开发者门户审批，也没有 OAuth 折腾：认证是一个请求头。新密钥来自控制台，快速上手指南则端到端覆盖搭建。

检测一条帖子是否是一篇 X Article {#detecting-whether-a-post-is-an-x-article}

在一条实时数据管道里，你很少有一份干净的文章 URL 列表；你有的是一条帖子流，有些是普通推文，有些是 Articles 的公告推文。公告推文用的是通常的 x.com/{username}/status/{id} 路径，所以光看 URL 无法识别。可靠的做法是先尝试文章接口，在响应缺少实质正文时回退到一次标准推文查找。

import requests
from typing import Literal, TypedDict

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

class Content(TypedDict):
    type: Literal["article", "tweet"]
    data: dict

def get_content(tweet_link: str) -> Content:
    """如果链接是一篇 Article 就返回一个文章对象，否则返回推文。"""
    headers = {"ApiKey": API_KEY, "Content-Type": "application/json"}

    try:
        resp = requests.post(
            f"{BASE_URL}/article",
            headers=headers,
            json={"tweet_link": tweet_link},
            timeout=30,
        )
        if resp.status_code == 200:
            article = resp.json()
            # Articles 携带一个实质正文。一个短的或缺失的
            # full_text 意味着这不是一篇 Article。
            if article.get("full_text") and len(article["full_text"]) > 500:
                return {"type": "article", "data": article}
    except requests.RequestException:
        pass

    resp = requests.post(
        f"{BASE_URL}/tweet-info",
        headers=headers,
        json={"tweet_link": tweet_link},
        timeout=30,
    )
    resp.raise_for_status()
    return {"type": "tweet", "data": resp.json()}

500 字符的阈值在实践中很好用。要更严格，也查 cover_image_url 或 published_at，两者都是 Article 特有字段。这里的单帖查找是 POST /v3/tweet-info，返回标准推文对象。

对标竞品文章 {#benchmarking-competitor-articles}

对标长文 Articles，意味着拉每一篇的指标，并按浏览量做规范化，因为原始计数偏袒有更大受众的账号。对 Articles 最要紧的信号，是每 1,000 次浏览的互动，和每 1,000 次浏览的收藏率。收藏追踪的是稍后再看的意图，与深度和权威相关，而在普通推文上几乎不显现。

import requests
from dataclasses import dataclass
from datetime import datetime

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

@dataclass
class ArticleMetrics:
    author: str
    published_at: datetime
    views: int
    likes: int
    bookmarks: int
    replies: int
    retweets: int
    quotes: int
    body_length: int

    @property
    def engagement_rate(self) -> float:
        """每 1,000 次浏览的互动事件。"""
        if self.views == 0:
            return 0.0
        total = self.likes + self.bookmarks + self.replies + self.retweets + self.quotes
        return (total / self.views) * 1000

    @property
    def bookmark_rate(self) -> float:
        """每 1,000 次浏览的收藏。"""
        if self.views == 0:
            return 0.0
        return (self.bookmarks / self.views) * 1000


def fetch_article_metrics(tweet_link: str) -> ArticleMetrics:
    resp = requests.post(
        f"{BASE_URL}/article",
        headers={"ApiKey": API_KEY, "Content-Type": "application/json"},
        json={"tweet_link": tweet_link},
        timeout=30,
    )
    resp.raise_for_status()
    a = resp.json()
    return ArticleMetrics(
        author=a["author"]["username"],
        published_at=datetime.fromisoformat(a["published_at"].replace("Z", "+00:00")),
        views=a["views_count"],
        likes=a["likes_count"],
        bookmarks=a["bookmark_count"],
        replies=a["reply_count"],
        retweets=a["retweet_count"],
        quotes=a["quote_count"],
        body_length=len(a["full_text"]),
    )


def benchmark(article_links: list[str]) -> list[ArticleMetrics]:
    results = []
    for link in article_links:
        try:
            results.append(fetch_article_metrics(link))
        except requests.HTTPError as e:
            print(f"Skipping {link}: {e}")
    return sorted(results, key=lambda m: m.engagement_rate, reverse=True)

构建文章 URL 的输入列表是一个单独的步骤：扫描每个观察列表账号的近期帖子，保留那些正文只是一个到 x.com/i/article 的 t.co 链接的帖子。一次对 50 篇竞品 Articles 的对标是 50 次请求，舒舒服服在入门套餐之内；每周跑一次，每个竞品一个月也就几百次请求。对批处理模式和游标处理，见优化 API 使用。

用 NLP 分析文章内容 {#analyzing-article-content-with-nlp}

文章正文很适合 NLP，因为文本干净：书写、编辑并结构化，几乎没有那种让短推文难以建模的噪音。你几乎不用预处理，就能把 full_text 直接传进一个情感或摘要模型。取回和分析是两层：先取回文章对象，再把它的正文交给你所用的任何模型提供方。

import os
import requests

SORSA_KEY = os.environ["SORSA_API_KEY"]

def fetch_article(tweet_link: str) -> dict:
    resp = requests.post(
        "https://api.sorsa.io/v3/article",
        headers={"ApiKey": SORSA_KEY, "Content-Type": "application/json"},
        json={"tweet_link": tweet_link},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()


def build_prompt(article: dict) -> str:
    return (
        "Analyze this X Article. Return JSON with: sentiment "
        "(positive, negative, neutral, or mixed), main_topics (3 to 5 tags), "
        "and a 2 to 3 sentence neutral summary.\n\n"
        f"Body:\n{article['full_text']}"
    )

# 把 build_prompt(fetch_article(link)) 传给你选择的模型提供方。

因为单个密钥处理每秒 20 次请求，取回很少是瓶颈，模型层才是。对高吞吐，先取回文章，再对着你提供方的并发限制并行分析。把这当作对着一份作者观察列表的每日作业，很好用。

定价和速率限制 {#pricing-and-rate-limits}

文章取回从每 1,000 篇文章 $1.80 起（在最大套餐上每篇 $0.0018）。每次取回都算作月度配额里的一次请求，不管正文多长。没有按字符计费、没有针对封面图的附加费，也没有针对这个接口的单独速率限制。每秒 20 次请求的限制一律适用，而一次单篇文章调用很少成为瓶颈。每个新密钥都注册即送 100 次免费请求（无需绑卡），永不过期、跨全部 40 个接口有效，所以文章接口能在选一个套餐之前先练手。

多数账号一周发布不到一篇 Article，所以每周从 200 个观察列表作者取回每一篇 Article，大约跑 800 到 2,000 次请求，舒服地落在 Starter 套餐之内，还给其他接口留有余量。完整套餐细节在 Sorsa API 定价拆解里；官方 X API 和一个按请求计费模型之间的每次调用经济性，在当前 X API 定价指南里拆解。如果你在搬移一个现有集成，从官方 X API 的迁移路径映射接口和认证变更。

一个约十人的 B2B SaaS 竞争情报团队，想每周追踪大约 150 到 200 个竞品和分析师账号的长文 Articles。在官方 X API 上正文就是不可及，所以现实的替代方案，是一个带 cookie 轮换和挑战处理的无头浏览器爬取集群。切到一个直接文章接口，把这个作业变成一个月几百到几千次请求，舒服地落在入门套餐之内，没有爬取基础设施要维护。这个胜利不是一个调优过的百分比，而是为本应一次 REST 调用就能拿到的数据，移除了一整个维护面。

开始上手

从零到一次可用文章取回最快的路：

1. 把一个文章推文 URL 粘进 API Playground、在写任何代码之前在浏览器里看 JSON 响应。
2. 从控制台拉一个 API 密钥、跑上面的 curl 调用。
3. 把 Python get_article 函数放进一个笔记本来确认集成，然后为生产加对 429 的重试和一个持久化层。

认证是一个 ApiKey 请求头，搭建只需几分钟，没有审批队列，每个接口共享同样的固定每秒 20 次请求。新账号注册即送 100 次免费请求（无需绑卡），永不过期、覆盖全部 40 个接口。之后文章取回从每 1,000 篇 $1.80 起，从与读取 API 其余部分相同的配额里支取，所以把这个接口加进一个现有工作流，不需要单独的集成。

常见问题 {#faq}

X Articles 通过官方 X API 可用吗？

不直接。官方 X API 没有文章特有接口；宣告一篇 Article 的推文，其文本字段里只含一个 t.co 链接，没有正文、封面图或发布日期。note_tweet 字段覆盖的是 2.5 万字符的长帖，那是另一个功能。要取回文章正文，你要么对着渲染的页面跑浏览器自动化，要么用一个解析文章对象的第三方 REST API。

X Articles 和长帖有什么区别？

长帖（扩展帖）是对 Premium 订阅者最多 2.5 万字符的推文；它们带一个“显示更多”按钮内联出现，没有单独发布日期、没有封面图，也没有格式。X Articles 是一个最多约 10 万字符的单独格式，带标题、粗体和斜体文本、列表、嵌入媒体、一张封面图，和资料上一个专门的 Articles 标签。Articles 更接近一篇 Substack 帖子，而不是一条推文。

你如何取回一篇 X Article 的完整文本？

把公告推文的 URL 或数字 ID 发给一个文章接口，读 JSON 响应。在 Sorsa API 上，POST /v3/article 在单次请求里返回完整正文、预览文本、封面图、发布日期和互动计数，用一个 ApiKey 请求头认证，无 OAuth。每次调用算作套餐配额里的一次请求。

你能取回过去发布的 X Articles 吗？

能，只要那篇 Article 在 X 上仍公开。Articles 一旦发布就有一个永久 URL，所以任何历史 Article 都可按其公告推文 URL 或 ID 取回。如果作者稍后删除那篇 Article，查找返回一个未找到错误。对 Articles 之外较旧的推文存档，一个专门的历史取回工作流会一路回溯翻页到一个账号的第一条帖子。

通过 API 拉 X Article 内容要花多少钱？

在 Sorsa API 上，一次文章取回就是一次单独请求，定价从每 1,000 篇文章 $1.80 起（在最大套餐上每篇 $0.0018），不管正文多长都没有按字符附加费。每个新密钥注册即送 100 次免费请求（无需绑卡），永不过期、跨全部 40 个接口有效，所以这个接口能在投入一个套餐之前先试。一周取回几百篇 Articles 塞进入门套餐，还有配额剩给其他接口。

你如何在取回一条帖子之前判断它是否是一篇 X Article？

公告推文用正常的 x.com/{username}/status/{id} 路径，所以光看 URL 不是一个可靠信号。可靠的方法是先调用文章接口，只在 full_text 有实质内容时才把结果当作一篇 Article（一个 500 字符阈值很好用）；一个短的或缺失的正文，意味着这是一条普通帖子。cover_image_url 或 published_at 存在，则进一步确认。

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

本指南取材于在生产里运行 Sorsa /article 接口的亲手工作、当前 Sorsa API v3 参考的字段和参数名，以及接口本身的实时响应形状。功能时间线和奖金细节对照 Engadget 对 2024 年 3 月上线和约 10 万字符限制的报道、以及 Social Media Today 对 2026 年 1 月 Premium 扩展和 100 万美元 Article 竞赛的报道核验。接口能力和定价反映 Sorsa 发布的套餐。核验于 2026 年 7 月 8 日。