logo

Twitter 账号帖子列表采集

给一个 Twitter 账号编号，返回该账号下已发布帖子的编号与发布时间清单

数据获取X (Twitter)帖子动态

概览

想摸清某个 Twitter 账号最近发了哪些帖、按时间怎么排列——但手动翻时间线太低效？给一个账号编号，任务在后台完成后，你会拿到该账号下已发布帖子的编号与发布时间清单，可以直接做时间线分析或交给详情类 App 继续补字段。

比起在主页里一页页翻历史帖子，它把指定账号的公开帖子列表一次拉齐并按发布时间从新到旧排列，每条帖子一行，适合当作账号内容节奏分析、历史帖子盘点和下游详情采集的入口数据。

数据说明

清单取自指定 Twitter 账号的公开发帖记录，默认按发布时间从新到旧返回，同一个帖子编号只出现一次。发布时间是平台展示的帖子发布时间；采集时间与更新时间分别为结果被抓取和清洗落库的时间点。仅覆盖公开可见帖子，受保护账号或未公开内容不在其中。单次任务只针对一个账号编号，实际返回条数不超过你设定的「最多采集条数」。本 App 返回帖子编号与时间等列表字段，不含帖子正文与互动数。

结果长什么样

每条记录是一条帖子：

帖子编号发布时间关联类型提交账号编号采集时间
20902738739883254642023-01-07T16:15:39account16116375889218150402026-08-25T14:44:45
20645434527640211872026-06-10T11:01:31account16116375889218150402026-08-25T13:43:05

另有更新时间、关联编号、无数据标记等字段。

应用场景

  • 分析发文节奏时，按「发布时间」排序，看账号在什么时段更活跃、最近是否停更。
  • 搭建采集流水线时，把「帖子编号」清单交给详情类 App，逐条补齐正文与互动数据。
  • 做历史盘点时，对同一「提交账号编号」定期跑任务，比对新增「帖子编号」识别新发布内容。
  • 评估账号体量时，结合返回条数与「最多采集条数」设置，判断是否需要提高采集上限。

适用边界

单次仅支持一个账号编号；帖子条数由「最多采集条数」控制，默认 100 条、上限 1000 条。

  • 适合用于
  • 需要获取某个 Twitter 账号已发布帖子的编号与时间线清单时
  • 已有账号编号，想批量拿到帖子 ID 再交给详情类 App 深挖时
  • 不要用于
  • 只有用户名、还没有账号编号时——先用账号信息采集类 App 获取编号
  • 需要帖子正文、互动数等完整详情时——本 App 只返回帖子编号与时间等列表字段

失败处理

作者声明的失败与重试处理方式，接入时建议一并写进系统提示词。

  1. 1任务失败或过期可原样重新提交
  2. 2账号无公开帖子或编号无效时可能返回空列表或标记为无数据
  3. 3鉴权失败属不可重试错误，需先配置有效 API 密钥

输入参数

调用本 App 需要传入的参数，与 manifest.json 的 input.schema 同源。

字段名业务名称类型必填默认值枚举 / 约束示例说明
account_id账号编号string是——1611637588921815040要采集帖子列表的 Twitter 账号编号（纯数字 account ID），可从账号信息采集结果中的「账号编号」字段获取
max_posts最多采集条数integer否1001–1000—本次任务最多采集多少条帖子，不填默认 100 条；值越大耗时和费用越高

输出数据

单条记录的字段结构，与 manifest.json 的 output.schema 同源。

字段名业务名称类型示例说明
content_id帖子编号string—帖子在平台内的唯一编号
publish_time发布时间string—帖子公开发布时间
crawl_time采集时间string—本条结果被采集的时间
clean_update_time更新时间string—结果最近清洗落库的时间
keyword_type关联类型string—结果与提交参数的关联类型标识
related_id关联编号string—结果关联的账号或检索标识
biz_id业务标识string—该结果对应的业务对象标识
submitted_account_id提交账号编号string—本次任务提交时填写的账号编号
no_data无数据boolean—该账号是否未采集到有效帖子

记录 Schema

输出按记录逐条返回。记录主键为 content_id，去重、增量、关联以它为准。

output.schema
{
  "type": "object",
  "properties": {
    "content_id": {
      "type": "string",
      "title": "帖子编号",
      "description": "帖子在平台内的唯一编号"
    },
    "publish_time": {
      "type": "string",
      "title": "发布时间",
      "description": "帖子公开发布时间"
    },
    "crawl_time": {
      "type": "string",
      "title": "采集时间",
      "description": "本条结果被采集的时间"
    },
    "clean_update_time": {
      "type": "string",
      "title": "更新时间",
      "description": "结果最近清洗落库的时间"
    },
    "keyword_type": {
      "type": "string",
      "title": "关联类型",
      "description": "结果与提交参数的关联类型标识"
    },
    "related_id": {
      "type": "string",
      "title": "关联编号",
      "description": "结果关联的账号或检索标识"
    },
    "biz_id": {
      "type": "string",
      "title": "业务标识",
      "description": "该结果对应的业务对象标识"
    },
    "submitted_account_id": {
      "type": "string",
      "title": "提交账号编号",
      "description": "本次任务提交时填写的账号编号"
    },
    "no_data": {
      "type": "boolean",
      "title": "无数据",
      "description": "该账号是否未采集到有效帖子"
    }
  },
  "required": [],
  "additionalProperties": false
}

调用方式

本 App 支持通过 MCP、API、SDK 与文件导出方式接入，各接入方式共享同一套能力与计价。所有请求统一使用 Authorization: Bearer 请求头完成身份认证，凭证为 API Key（长期有效，在开放平台创建）；MCP 客户端另支持 OAuth 免密钥登录。CLI、Skill 等更多接入方式正在规划中。

通过 MCP（Model Context Protocol）协议，可在 Claude、Cursor 等 AI 客户端中直接调用本 App。选择你的客户端与认证方式，复制下方配置即可接入。

客户端配置

把 Bearer 后替换为长期有效的 API Key 即可，各类客户端与 CI、无浏览器环境通用。

mcpServers 配置
{
  "mcpServers": {
    "SpiderKing999__twitter-account-posts": {
      "type": "http",
      "url": "https://mcp-v2.bazhuayu.com?pin=SpiderKing999/twitter-account-posts",
      "headers": { "Authorization": "Bearer <YOUR_API_KEY>" }
    }
  }
}
查看我的 API Keys →

让 AI 自己完成配置

不想手动改配置？复制安装提示词，粘贴到任意 AI 客户端对话框，由它按自身方式完成接入（提示词会让 AI 向你索要 API Key，避免凭证留在对话记录或共享配置里）。

如需在同一个 MCP 连接里指定多个 App，前往 MCP 连接页（已为你指定本 App）。

价格

提交一次帖子列表采集

每提交一次任务计费一次，与返回条数无关。

¥0.05/ 次
返回一条帖子

按实际成功返回的数据条数计费，任务失败不计费。每 20 条为一个计费单位，不足 20 条按 20 条计。

¥0.006/ 20 条

多个计费事件按各自口径独立累计，具体以每一项说明为准；任务失败不计费。

查看余额

立即体验

填写参数直接运行，结果来自真实调用。

示例
参数按 input.schema 校验后提交
请先填写必填参数
¥0.006 / 20 条起