YouTube Transcripts in n8n: HTTP Request Workflow Guide

Import this directly via n8n's Import from File option (or paste it into Import from URL):

Get a key from the dashboard (100 free credits, no card required), then set it as an environment variable available to your n8n instance:

GETYOUTUBETRANSCRIPT_API_KEY=sk_live_...

The imported HTTP Request node reads it via {{ $env.GETYOUTUBETRANSCRIPT_API_KEY }} in its Authorization header - don't hardcode the key directly into the workflow JSON.

The HTTP Request node calls the transcript endpoint with the video ID as a query parameter:

GET https://getyoutubetranscript.com/api/v1/transcript?v={{ $json.videoId }}
Authorization: Bearer {{ $env.GETYOUTUBETRANSCRIPT_API_KEY }}

Feed a video ID into the workflow's input (or a previous node's output), and the node returns the transcript, title, author, and thumbnail as JSON at $json.data.transcript.

Feeding a list of video IDs straight into the HTTP Request node fires them all as fast as n8n can - fine for 5 videos, risky for 500 against a 60 req/min free-tier limit. n8n gives you two built-in ways to pace this:

• HTTP Request node → Add Option → Batching. Set Items per Batch (how many requests fire together) and Batch Interval (ms) (delay between batches). For the free plan's 60 req/min, a batch size of 5 with a 5,000ms interval keeps you comfortably under budget.
• Split In Batches + Wait node. The Split In Batches node divides your video list into chunks; a Wait node pauses between chunks before the loop continues to the next one. This is strictly sequential (no parallel burst at all), which is the safer choice if you're close to the limit or the API you're chaining downstream (e.g. an LLM summarizer) has its own throughput ceiling too.

Also set Wait Between Tries (ms) in the node's retry settings higher than your per-request budget - for a 60 req/min plan that's roughly one request per second on average, so 1,000ms+ between retries avoids immediately re-tripping the same limit on a 429.

When processing many videos, some will fail (private video, no captions, a transient 429). Enable Continue On Fail on the HTTP Request node so one failure doesn't halt the whole run, then add an IF node downstream to branch on the response - route successes to your summarizer and failures to a log or retry queue instead of losing the whole batch to one bad video ID.

Add an AI/LLM node after the HTTP Request node and reference {{ $json.data.transcript }} as its prompt input - this turns the workflow into a full "fetch transcript → summarize" pipeline with no manual copy-paste step. For a batch run, this same node runs once per item flowing through the loop, so a 50-video batch produces 50 summaries without additional wiring.