HomeBlogTranscribePlansAPI Keys

IFTTT YouTube 自动化：诚实地获取转录文本

IFTTT applet 的图表，将 YouTube 视频 URL 交给中间服务，该服务获取转录文本

IFTTT YouTube 自动化让你恰好到达转录文本管道的一半，我宁愿提前告诉你也不会让你在构建 applet 后发现。YouTube 触发器是可靠的。webhook 操作可以调用我的 API。但 IFTTT 丢弃响应——所以转录文本到达并立即蒸发。这是实际有效的。

IFTTT 做得好的

频道的新公开视频触发器是可靠且免费的。它在频道上传后不久触发，并给你视频 URL 和标题等成分。作为"YouTube 上发生的东西"铃声，IFTTT 真的没问题。

它在哪里破裂

IFTTT 的 Webhooks 服务有一个发出网络请求操作，是的，它可以发送一个 GET 到 https://youtube2text.org/api/transcribe 带视频 URL。请求会成功。API 将返回完整的转录文本作为 JSON。

然后 IFTTT 丢弃它。网络请求操作是即发即忘：没有 JSON 解析、没有响应成分、没有方法将 result.content 传递到下一步——因为根本没有下一步。Applet 是两个槽，触发器和操作，操作的输出无处去。这是整个平台对这个工作的诚实限制，没有 applet 配置绕过它。

中间人模式

修复是让 IFTTT 做它擅长的一件事——注意新视频——并将真正的工作交给可以读取响应的东西：

  1. IFTTT 触发器： YouTube——频道的新公开视频。
  2. IFTTT 操作： Webhooks——发出网络请求，指向你的中间人 URL，在查询字符串或主体中传递视频 URL 成分。
  3. 中间人： 接收 ping，调用 GET https://youtube2text.org/api/transcribe?url=<VIDEO_URL>&maxChars=20000 带 x-api-key 标头，并做你想要的任何事——写入表、发布到 Slack、通过电子邮件发送摘要。

中间人可以是 Google Apps Script 网络应用（一个 doGet 函数加 UrlFetchApp.fetch，部署为网络应用——我在Google Sheets 指南中使用的相同构建块）、n8n Webhook 触发器，或 Make 自定义 webhook。十到二十行逻辑，无论你选择哪个。

对于测试，API 有一个无需注册的免费共享密钥：请求 https://youtube2text.org/api/demo-key 你得到 {"success": true, "apiKey": "yt_..."}——每个 IP 每月好用 5 个视频。你的中间人应该容忍一件事：没有字幕的视频返回 404，代码 TRANSCRIPT_UNAVAILABLE，这是 API 礼貌地说从来没有任何东西要转录。

我的实际建议

一旦你已经站起来中间人，问 IFTTT 仍然贡献什么。答案是：一个你可以用 RSS 提要替换的触发器。每个 YouTube 频道发布一个：

https://www.youtube.com/feeds/videos.xml?channel_id=CHANNEL_ID

n8n 和 Make 都可以本地监视该提要，这将两跳架构折叠为单个工具，自己触发、获取转录文本、解析 JSON 并传递输出。我已经逐端写了两个：n8n 工作流（如果自托管免费、我的选择）和 Make 场景（如果你想要托管和可视化更友好）。

仅在它已经接入你无法轻易移动的东西时才保持 IFTTT 在循环中——一个智能家庭例程、一个移动通知设置、一个 applet 生态你的团队依赖。作为触发器它仍然在那里赚得它的槽。作为转录文本管道，它从不会单独完成工作。

密钥，当你准备好

无论你构建什么形状，转录文本部分是一个带一个标头的 HTTP 调用。在 youtube2text.org/app/keys 用 Google 登录得到你自己的密钥——无电话、无卡。免费层是每月 5 个视频，5.99 美元涵盖 50，9.99 美元涵盖 500，19.99 美元是无限。中间人模式花费你二十行代码；转录文本花费少于那个。