YouTube Transcript API Rate Limit: What It Is and How to Handle 429s

These are two different constraints that get confused often:

• Quota - total requests allowed over a longer window (e.g. a day). Running out means waiting for a reset, sometimes many hours away.
• Rate limit - requests allowed per short window (e.g. a minute). Hitting it means slowing down for seconds to a minute, not hours.

Under the hood, most APIs implement rate limiting with either a token bucket (you accumulate request "tokens" at a steady rate and spend one per request, allowing short bursts) or a fixed/sliding window counter (a hard cap per calendar minute, resetting on the boundary). Which one a given API uses changes how bursty your traffic can safely be - a token bucket tolerates a short spike better than a fixed window does.

429 Too Many Requests isn't provider-specific folklore - it was formally defined in RFC 6585 (April 2012) as a standard HTTP status code. Per RFC 9110, a compliant server may attach a Retry-After header to a 429 (or 503) response, in one of two forms:

• Delay-seconds form - an integer, e.g. Retry-After: 120, meaning wait 120 seconds.
• HTTP-date form - an absolute timestamp, e.g. Retry-After: Wed, 21 Oct 2026 07:28:00 GMT.

When present, this header is authoritative - the server is telling you exactly when it'll accept requests again. Don't layer your own exponential backoff on top of it; that only delays your recovery further. Only fall back to backoff when the header is absent.

The correct order of operations: check for Retry-After first, and only fall back to exponential backoff with jitter if it's missing. Jitter (randomizing the wait slightly) matters because when many clients hit a limit simultaneously and all retry on an identical schedule, they synchronize and create a "thundering herd" that immediately re-trips the same limit.

Node.js:

async function getTranscriptWithRetry(videoId, apiKey, maxRetries = 4) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const res = await fetch(
      `https://getyoutubetranscript.com/api/v1/transcript?v=${videoId}`,
      { headers: { Authorization: `Bearer ${apiKey}` } }
    );
    if (res.status !== 429) return res.json();

    const retryAfter = res.headers.get('retry-after');
    const waitMs = retryAfter
      ? Number(retryAfter) * 1000
      : 500 * 2 ** attempt + Math.random() * 250; // exponential backoff + jitter
    await new Promise((r) => setTimeout(r, waitMs));
  }
  throw new Error('Rate limited after retries');
}

Python:

import os, time, random, requests

def get_transcript_with_retry(video_id, api_key, max_retries=4):
    url = "https://getyoutubetranscript.com/api/v1/transcript"
    for attempt in range(max_retries + 1):
        res = requests.get(url, params={"v": video_id}, headers={"Authorization": f"Bearer {api_key}"})
        if res.status_code != 429:
            return res.json()

        retry_after = res.headers.get("Retry-After")
        wait = float(retry_after) if retry_after else (0.5 * 2 ** attempt + random.uniform(0, 0.25))
        time.sleep(wait)
    raise RuntimeError("Rate limited after retries")

A request-per-minute ceiling and an in-flight concurrency ceiling are not the same thing. Firing 50 requests simultaneously with Promise.all can trip a 429 even if your total for the minute is well under budget, because the server (or a proxy in front of it) may also cap simultaneous connections. When batch-processing many videos, cap concurrency independently of your rate-limit backoff:

import pLimit from 'p-limit';

const limit = pLimit(5); // at most 5 requests in flight at once
const results = await Promise.all(
  videoIds.map((id) => limit(() => getTranscriptWithRetry(id, apiKey)))
);

For sustained high-volume batches, upgrading plan tier raises the req/min ceiling directly - see pricing in the API docs, or start with 100 free credits from the dashboard.