IFTTT YouTube Automation: Getting Transcripts the Honest Way

IFTTT YouTube automation gets you exactly halfway to a transcript pipeline, and I'd rather tell you that up front than let you find out after building the applet. The YouTube trigger is solid. The webhook action can call my API. But IFTTT throws the response away — so the transcript arrives and immediately evaporates. Here's what actually works.

What IFTTT does well

The New public video by channel trigger is reliable and free. It fires shortly after a channel uploads and hands you ingredients like the video URL and title. As a "something happened on YouTube" bell, IFTTT is genuinely fine.

Where it breaks

IFTTT's Webhooks service has a Make a web request action, and yes, it can send a GET to https://youtube2text.org/api/transcribe with the video URL. The request will succeed. The API will return the full transcript as JSON.

And then IFTTT discards it. The web request action is fire-and-forget: no JSON parsing, no response ingredients, no way to pass result.content to a next step — because there is no next step. Applets are two slots, trigger and action, and the action's output goes nowhere. This is the honest limitation of the whole platform for this job, and no applet configuration gets around it.

The middleman pattern

The fix is to let IFTTT do the one thing it's good at — noticing the new video — and hand the real work to something that can read a response:

1. IFTTT trigger: YouTube — New public video by channel.
2. IFTTT action: Webhooks — Make a web request, pointed at your middleman's URL, passing the video URL ingredient in the query string or body.
3. Middleman: receives the ping, calls GET https://youtube2text.org/api/transcribe?url=<VIDEO_URL>&maxChars=20000 with an x-api-key header, and does whatever you wanted — writes to a sheet, posts to Slack, emails a summary.

The middleman can be a Google Apps Script web app (a doGet function plus UrlFetchApp.fetch, deployed as a web app — the same building block I used in the Google Sheets guide), an n8n Webhook trigger, or a Make custom webhook. Ten to twenty lines of logic, whichever you pick.

For testing, the API has a free shared key with no signup: request https://youtube2text.org/api/demo-key and you get {"success": true, "apiKey": "yt_..."} — good for 5 videos a month per IP. One thing your middleman should tolerate: videos without captions return a 404 with code TRANSCRIPT_UNAVAILABLE, which is the API's polite way of saying there was never anything to transcribe.

My actual recommendation

Once you're standing up a middleman anyway, ask what IFTTT is still contributing. The answer is: a trigger you can replace with an RSS feed. Every YouTube channel publishes one:

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

Both n8n and Make can watch that feed natively, which collapses the two-hop architecture into a single tool that triggers itself, fetches the transcript, parses the JSON, and delivers the output. I've written both up end to end: the n8n workflow (free if self-hosted, my pick) and the Make scenario (friendlier if you want hosted and visual).

Keep IFTTT in the loop only if it's already wired into something you can't easily move — a smart-home routine, a mobile notification setup, an applet ecosystem your team depends on. As a trigger it still earns its slot there. As a transcript pipeline, it was never going to finish the job alone.

Keys, when you're ready

Whichever shape you build, the transcript half is one HTTP call with one header. Sign in with Google at youtube2text.org/app/keys for your own key — no phone, no card. Free tier is 5 videos a month, $5.99 covers 50, $9.99 covers 500, and $19.99 is unlimited. The middleman pattern costs you twenty lines of code; the transcripts cost less than that.