X的开发者平台现在按请求收费，而不是按订阅档位收费。创建帖子按每次调用计费，POST /2/tweets 限制为每用户每15分钟100次请求，每应用每24小时10,000次。如果你正在考虑是否直接基于它进行开发，这两个事实将决定你架构中的大部分设计。
X API 到底收费多少？
官方定价页面描述的是一种额度模型，而非命名档位。你购买额度，设定支出上限，每次调用都从余额中扣除。
| 操作 | 标注价格 |
|---|---|
| 创建帖子 | 每请求0.015美元 |
| 含链接的帖子 | 每请求0.200美元 |
| 帖子（summoned） | 每请求0.010美元 |
| 私信与用户互动 | 每请求0.015美元 |
| 删除互动 | 每请求0.010美元 |
| 读取：帖子 | 每资源0.005美元 |
| 读取：用户、私信、关注/粉丝 | 每资源0.010美元 |
| 读取：点赞、静音、屏蔽 | 每资源0.001美元 |
| 读取自有数据（你自己的数据） | 每资源0.001美元 |
有两个细节比单价本身更重要。含链接的帖子价格是普通帖子的13倍以上，如果你靠发布链接为生，这是一笔不容忽视的开支。而且按量付费的方案在每个月度计费周期内，帖子读取上限为300万次，购买再多额度也无法突破这个上限。
资源在24小时的UTC窗口内会去重计费，因此同一天内两次请求同一个资源，只会计费一次。
提示： 本文数据是截至2026年9月，对照 docs.x.com/x-api/getting-started/pricing 核实的。各平台可能随时调整这些数据，不另行通知。
我们无法核实的部分。 网上广泛流传着带有月度发帖上限的旧版Free、Basic和Pro档位信息。我们没能找到列出这些档位的官方页面：目前的定价和介绍页面描述的是按量付费模式，没有命名档位，而档位对应的URL返回404。我们不会转述来自第三方的数字。请以开发者控制台中适用于你账号的实际费率为准。
X API 能发布什么内容，又不能发布什么？
POST /2/tweets 接受 text、可选的 media.media_ids、reply、poll、geo、reply_settings，以及少数几个标志位，例如 made_with_ai 和 paid_partnership。
媒体不包含在这次调用中。你需要通过分块上传接口单独上传，并传入生成的 media_id。一条帖子最多接受4张照片、1个动图，或1个视频。
以下几点在你投入开发之前值得先了解清楚：
quote_tweet_id仅限企业版使用。 引用发帖功能在通用接口中不可用。- 视频时长上限取决于发帖账号，而非你的应用。 标准账号上限为20分钟和8 GB；X Premium和认证账号上限为125分钟和16 GB。你的上传器必须同时处理这两种情况，因为这个限制归属于你代表其发帖的用户。
- 投票功能有限制。 选项数为2到4个，持续时间为5到10,080分钟。
- 创建接口的参考文档未标注字符限制。 我们无法从该页面核实这一点。产品实际执行的限制，请参见X字符限制文章。
提示： 本文数据是截至2026年9月，对照 docs.x.com/x-api/posts/creation-of-a-post 核实的。各平台可能随时调整这些数据，不另行通知。
用通俗的话说，认证模型是怎样的？
有两种模式，而发帖只能在其中一种下进行。
仅应用级Bearer令牌。 代表你的应用的单一凭证，可以读取公开数据，但无法发帖，因为没有代表的具体用户。
带PKCE的OAuth 2.0授权码模式，用户上下文。 用户被跳转到X的授权对话框，返回一个授权码，你用它换取访问令牌。发帖需要 tweet.write 权限范围，以及 tweet.read 和 users.read。如果你希望在访问令牌过期后继续发帖，必须在授权时请求 offline.access，这正是刷新令牌得以签发的原因。
最后这一点最容易让人栽跟头。offline.access 是按每次授权单独选择开启的。如果遗漏，每个用户都必须手动交互式重新授权，这对一个凌晨3点自动发布的定时工具来说是致命的。文档没有说明访问令牌的有效期，请按短期有效来处理，并主动提前刷新。
发帖的速率限制是多少？
| 接口 | 每用户 | 每应用 |
|---|---|---|
POST /2/tweets | 每15分钟100次 | 每24小时10,000次 |
每个响应都携带 x-rate-limit-limit、x-rate-limit-remaining 和 x-rate-limit-reset（一个Unix时间戳）。应该读取这些字段，而不是自己数调用次数，因为一旦发生重试，你自己的计数和X的计数就会出现偏差。
文档明确指出，速率限制和计费是两个独立的问题。不超过速率限制并不能限制你的支出，设定支出上限也不能阻止你收到429错误。这两种控制手段你都需要。
提示： 本文数据是截至2026年9月，对照 docs.x.com/x-api/fundamentals/rate-limits 核实的。各平台可能随时调整这些数据，不另行通知。
真正会耗费你三周时间的是什么？
不是发布这个调用本身，那个调用一个下午就能搞定。
令牌刷新。 请求 offline.access、加密存储刷新令牌、处理令牌轮换，以及为刷新失败的用户提供重新连接的路径。这是一项有自己一整套失败模式的后台工作，而不是一个简单的函数。
分块媒体上传。 INIT、APPEND、FINALIZE，然后轮询处理状态，直到 media id 可以被用于帖子中。视频转码可能会失败，而且是在你的上传接口已经返回200之后才失败。
每账号视频时长上限。 20分钟还是125分钟，取决于你在为谁发帖，这是一个运行时分支判断，仅凭你的应用凭证是无法得知的。
成本核算。 按请求计费意味着必须有人把支出分摊到具体客户身上，否则你会在账单上才发现链接附加费的存在。
429错误处理不能只是简单地休眠等待。 每用户的时间窗口是15分钟，一个简单粗暴的重试循环会把一次被限流的发帖变成一个卡死的工作进程。
简而言之
- 定价采用按量付费的额度模式。创建帖子每请求0.015美元；含链接的帖子为0.200美元。
- 按量付费方案的读取操作，每个月度计费周期上限为300万条帖子。
POST /2/tweets允许每用户每15分钟100次，每应用每24小时10,000次。- 发帖需要带
tweet.write的OAuth 2.0 PKCE用户上下文，如果想要刷新令牌，还需要offline.access。 - 媒体需单独上传：4张照片、1个动图，或1个视频。引用发帖仅限企业版。
- 截至2026年9月，命名的Free/Basic/Pro档位无法通过官方页面核实。
一次搞定，而不是每个平台各搞一次
上面这些工作是实打实的，而且是X特有的。LinkedIn需要两个各自拥有不同权限范围的独立应用。TikTok要求通过Content Posting API审计。Threads采用先创建容器再发布的流程，配合60天的令牌刷新周期。这些经验都无法互相套用。
BulkPublish 提供一套统一的REST API，覆盖15个平台：Facebook、Instagram、TikTok、YouTube、X、Bluesky、Threads、Pinterest、LinkedIn、Google Business Profile、Mastodon、Discord、Telegram、Tumblr 和 Snapchat。一种认证模式，一条媒体处理流程，一个统一的帖子对象，各平台的令牌刷新和异步状态轮询都在背后被统一处理。开发者文档和REST API参考介绍了各个接口。