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

ये दो अलग-अलग सीमाएं हैं जिन्हें अक्सर आपस में मिला दिया जाता है:

• कोटा - एक लंबी विंडो (जैसे एक दिन) में अनुमत कुल रिक्वेस्ट। खत्म होने का मतलब है एक रीसेट का इंतजार, जो कभी-कभी कई घंटे दूर होता है।
• रेट लिमिट - एक छोटी विंडो (जैसे एक मिनट) में अनुमत रिक्वेस्ट। इसे टकराने का मतलब है कुछ सेकंड से एक मिनट तक धीमा होना, घंटों नहीं।

इसके पीछे, ज्यादातर APIs रेट लिमिटिंग को या तो एक token bucket (आप एक स्थिर दर पर रिक्वेस्ट "टोकन" जमा करते हैं और प्रति रिक्वेस्ट एक खर्च करते हैं, जिससे छोटे बर्स्ट की अनुमति मिलती है) या एक fixed/sliding window counter (हर कैलेंडर मिनट पर एक सख्त सीमा, बाउंड्री पर रीसेट होती हुई) से लागू करते हैं। कौन सा इस्तेमाल होता है यह बदल देता है कि आपका ट्रैफिक कितना बर्स्टी सुरक्षित रूप से हो सकता है - एक token bucket एक fixed window से बेहतर एक छोटे स्पाइक को सह लेता है।

429 Too Many Requests कोई प्रोवाइडर-स्पेसिफिक कहानी नहीं है - इसे औपचारिक रूप से RFC 6585 (अप्रैल 2012) में एक मानक HTTP स्टेटस कोड के रूप में परिभाषित किया गया था। RFC 9110 के अनुसार, एक कंप्लायंट सर्वर 429 (या 503) रिस्पॉन्स पर एक Retry-After हेडर जोड़ सकता है, दो रूपों में से किसी एक में:

• Delay-seconds रूप - एक इंटीजर, जैसे Retry-After: 120, यानी 120 सेकंड इंतजार करें।
• HTTP-date रूप - एक एब्सोल्यूट टाइमस्टैम्प, जैसे Retry-After: Wed, 21 Oct 2026 07:28:00 GMT।

जब मौजूद हो, यह हेडर निर्णायक है - सर्वर आपको ठीक-ठीक बता रहा है कि वह फिर से कब रिक्वेस्ट स्वीकार करेगा। इसके ऊपर अपना खुद का एक्सपोनेंशियल backoff न लगाएं; इससे आपकी रिकवरी और देरी से होगी। केवल तभी backoff पर वापस जाएं जब हेडर मौजूद न हो।

सही क्रम है: पहले Retry-After जांचें, और अगर वह मौजूद न हो तभी jitter के साथ एक्सपोनेंशियल backoff पर वापस जाएं। Jitter (इंतजार को थोड़ा रैंडम करना) मायने रखता है क्योंकि जब कई क्लाइंट एक साथ किसी सीमा से टकराते हैं और सभी एक जैसे शेड्यूल पर रिट्राई करते हैं, तो वे सिंक्रोनाइज़ हो जाते हैं और एक "थंडरिंग हर्ड" बना देते हैं जो तुरंत उसी सीमा को फिर से टकरा देता है।

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")

एक requests-per-minute सीमा और एक इन-फ्लाइट कॉन्करेंसी सीमा एक जैसी चीज़ नहीं हैं। Promise.all के साथ एक साथ 50 रिक्वेस्ट फायर करना एक 429 ट्रिगर कर सकता है भले ही आपका मिनट का टोटल बजट के अंदर हो, क्योंकि सर्वर (या उसके सामने कोई प्रॉक्सी) एक साथ चल रहे कनेक्शन भी सीमित कर सकता है। कई वीडियो बैच-प्रोसेस करते समय, अपनी रेट-लिमिट 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)))
);

सस्टेन्ड हाई-वॉल्यूम बैचों के लिए, प्लान टियर अपग्रेड करने से req/min सीमा सीधे बढ़ती है - API docs में प्राइसिंग देखें, या dashboard से 100 फ्री क्रेडिट्स से शुरू करें।