Twitter / X API for Make and Zapier
让 Make 和 Zapier 继续拿到 Twitter/X 数据，而不是被原生集成卡住
很多 Make 和 Zapier 用户并不是想买一整套社媒工具，而是想在已有 scenario 或 Zap 里稳定拿到公开 Twitter/X 搜索结果、账号上下文、时间线和监控数据。TwtAPI 更适合做这类数据步骤，尤其是在原生 X 集成下线、受限、要求自己提供 X developer credentials，或者不适合长期监控时。它可以放在 Make HTTP 模块、Zapier Webhooks、API Request 或 Code 步骤后面，再把结果由自建流程写入表格、Slack、邮件或 AI。
快速结论
先看这页最重要的判断
如果你只是想先判断这条路线适不适合自己，先看这几条就够了。
这页解决什么问题
这里讨论的是公开数据读取和监控流程，不是替代所有官方 X 账号操作。
- 当原生 X app 不再覆盖你的任务时，用 Make HTTP 或 Zapier Webhooks/API Request 调一条清楚的 Twitter/X 数据 API。
- 当平台移除或限制 X app 时，团队仍然需要让监控、报告或补全流程继续运行。
- 按计划监控品牌提及、关键词、活动、竞品或市场话题。
- 当原生 X app 被移除、下线或不再适合当前流程时，他们需要稳定的搜索、账号查询、时间线或监控响应。
决策指南
这页应该帮你做出什么判断
适合使用这条路线
当原生 X app 被移除、下线或不再适合当前流程时，他们需要稳定的搜索、账号查询、时间线或监控响应。
先不要用这条路线
如果这只是一次人工查看，或者团队真正需要的是现成 dashboard、席位、报表和审批流程，先比较 SaaS 工具再决定是否接 API。
第一步验证
选择能发起带认证 HTTP 请求并接收 JSON 的步骤。在 Zapier 里，这通常会是 Webhooks、Code，或者类似 API Request 的步骤。
成功信号
当平台移除或限制 X app 时，团队仍然需要让监控、报告或补全流程继续运行。
适合谁
适合需要 Twitter/X 数据，而不是继续拼 workaround 的自动化搭建者
最适合的场景，是 Twitter/X 负责提供数据，Make 或 Zapier 负责后续路由和动作。
用 Make HTTP 模块的团队
当原生 X app 被移除、下线或不再适合当前流程时，他们需要稳定的搜索、账号查询、时间线或监控响应。
用 Zapier Webhooks、API Request 或 Code 的团队
他们想让 Zap 继续跑下去，用清楚的 API 调用完成数据步骤，而不是等原生 Twitter 集成支持某个细分触发器。
被迫改成自带官方凭证的团队
他们可能还能在 Make 或 Zapier 里继续搭流程，但需要先判断：这个任务到底需要官方 X developer credentials，还是只是在读取公开数据。
做长期告警的市场和运营团队
他们想把高价值提及、竞品动态、话题变化、账号观察列表或每日摘要送到团队已经在用的工具里。
为什么这个页面值得做
Make 和 Zapier 相关搜索，很多时候是在问连续性、成本和稳定性
社区和帮助中心信号都指向同一个问题：原生 Twitter/X app 支持可能变化，也可能要求新的官方凭证或变得更贵，但自动化流程还需要继续拿数据。
原生 X 集成变化可能比业务流程更快
当平台移除或限制 X app 时，团队仍然需要让监控、报告或补全流程继续运行。
自带 X 凭证不等于检索问题已经解决
如果 Zap 或 scenario 现在要依赖你的 X app credentials，团队仍然要判断官方价格、权限、endpoint 覆盖、rate limits，以及这个流程是不是其实只需要公开数据。
Webhooks 和 Code 步骤需要稳定响应
一个 workaround 是否有用，取决于数据结构是否足够稳定，能不能继续接过滤、存储、告警和摘要。
读数据流程和发帖流程不是一回事
很多 Make 和 Zapier 讨论是在问怎么发 X，但监控流程通常相反：读取公开帖子、补上下文、写入表格、路由有用信号。两类任务应该分开判断。
官方 API 仍然适合账号动作
如果你要发帖、执行账号授权动作或处理合规场景，官方 X API 可能仍然是正确路径。公开数据搜索、账号查询、时间线和监控可以单独评估。
真正要算的是定时运行成本
一个每小时跑一次的 Make scenario 或 Zap，和一次测试请求不是同一件事。要一起看搜索量、账号查询、重试、失败恢复、写入次数和 AI 调用。
核心能力
Make 和 Zapier 里通常会用到这些 TwtAPI 能力
把这些能力当成 HTTP、Webhook、API Request 或 Code 步骤，再把响应交给过滤、Router、Path、表格、Slack、邮件或 AI 工具。
| 维度 | 该确认什么 | 为什么重要 |
|---|---|---|
| search_tweets | 搜索公开 Twitter/X 内容 | 按计划监控品牌提及、关键词、活动、竞品或市场话题。 |
| get_user_by_username | 补账号上下文 | 在路由前判断作者、竞品、客户、媒体或创始人账号是谁。 |
| get_user_tweets | 获取账号时间线 | 做竞品摘要、创始人监控或账号 watchlist，不必每天手动打开 X。 |
| webhook_ready | 把干净结果送进后续工具 | 把过滤后的结果由自建流程写入 Sheets、Airtable、Slack、Discord、Notion、邮件、队列或 LLM 摘要步骤。 |
| dedupe_and_recovery | 避免重复运行制造重复记录 | 保存 tweet ID、来源 URL、last-seen checkpoint 和投递状态，避免重试或漏跑回补时重复创建表格行、告警或摘要。 |
典型流程
一条实用的 Make / Zapier Twitter/X 数据流程
最稳的流程通常很朴素：获取、过滤、补上下文、路由，然后再决定是否提高频率。
- 1
从 HTTP、Webhooks 或 Code 调 TwtAPI
选择能发起带认证 HTTP 请求并接收 JSON 的步骤。在 Zapier 里，这通常会是 Webhooks、Code，或者类似 API Request 的步骤。
- 2
先从一个只读公开数据任务开始
先选一个具体任务，比如关键词监控、竞品账号更新、创始人观察列表、线索信号或每日摘要输入，不要一开始就重建所有旧 Twitter/X 自动化。
- 3
把公开数据读取和官方账号动作分开
公开搜索、账号查询、时间线和监控可以评估 TwtAPI；发帖、点赞、转发、关注或账号内动作，应该保留给官方 X 凭证路线。
- 4
先过滤，再发告警
去掉低价值匹配，处理重复内容，并在路由前补上账号上下文。
- 5
下一次定时运行前先保存状态
把 tweet ID、来源 URL、命中规则、作者、时间戳和 last-seen 状态保存到 Sheets、Airtable、Storage by Zapier、Make Data Stores 或自己的后端，重试时才不会乱。
- 6
把结果送进真正承接工作的工具
可以写入 Google Sheets 或 Airtable，发到 Slack 或 Discord，进入 Notion、Gmail，或者交给 AI 步骤生成摘要。
- 7
把重复运行算清楚
扩大之前，先估算自动化运行频率、结果数量、重试方式，以及每个后续动作的成本。
FAQ
Make 和 Zapier 用户常问的问题
这些回答重点放在现实自动化流程上，也避免把 TwtAPI 说成官方 X 能力的万能替代。
可以在 Make.com 里用 TwtAPI 吗？
可以。用 Make 的 HTTP 模块调用 TwtAPI 接口，再把 JSON 响应接到过滤器、Router、Sheets、Airtable、Slack、邮件或 AI 步骤里。
可以在 Zapier 里用 TwtAPI 吗？
可以。Zapier 的 Webhooks、API Request 或 Code 步骤可以调用带认证的 HTTP API。更适合公开搜索、账号查询、时间线、监控、数据补全，以及把结果由自建流程写入 Sheets、Airtable、Slack、邮件或 AI 步骤。
如果 Zapier 要求我自己提供 X Developer App，怎么办？
如果你要做官方账号动作，这条路可能是对的。但如果 Zap 只是要公开搜索、查用户、读时间线或做监控，可以先比较更聚焦的公开数据 API 路线，不一定要把更多官方凭证塞进自动化里。
如果 Make 里原来的 X 模块没有了，怎么处理？
如果只是读取公开数据，可以用 Make HTTP 重新搭数据步骤，后面继续接过滤、去重、路由和失败恢复。如果是发帖这类账号动作，就应该走官方账号授权路线。
这能替代 Make 或 Zapier 里的 Twitter 触发器吗？
如果是公开数据监控，很多时候可以：定时运行 scenario 或 Zap，调用 TwtAPI，过滤返回内容，再只把有用记录送到下游。如果是官方账号事件或写入动作，仍然应该走官方 X 路线。
怎么避免重复表格行或重复告警？
保存 tweet ID、来源 URL、命中规则和投递状态，可以放在 Sheets、Airtable、Make Data Stores、Storage by Zapier 或自己的后端里。创建表格行、发 Slack 告警或生成 AI 摘要之前，先查这份状态。
这是不是替代官方 X API？
不是。TwtAPI 不是官方 X API。如果你需要用自己的账号发帖或执行账号授权动作，官方 API 可能仍然需要。TwtAPI 更适合作为公开数据搜索、监控、账号查询、时间线和自动化输出的数据层。
为什么不直接用 scraper 或临时 workaround？
临时方案适合测试。但长期自动化需要稳定响应、重试、去重、失败恢复和可计算的成本。否则 Zap 或 scenario 跑起来以后，维护压力会转移到你自己身上。
选择数据源前应该比较什么？
看接口覆盖、响应结构、价格、限速、重试、失败恢复、重复数据处理，以及结果能不能稳定接到你的 Make 或 Zapier 流程里，而不是每次都要人工清洗。
下一步
给 Make 或 Zapier 流程换一个更稳定的 Twitter/X 数据步骤
先从一条真实自动化开始：一个查询、一个频率、一个输出位置、一个成功标准。跑通以后再决定是否扩大。