YouTube Transcript API Rate Limit: What It Is and How to Handle 429s
Why APIs return 429 Too Many Requests, what RFC 6585 and the Retry-After header actually specify, how rate limits differ from daily quota, and how to implement correct retry and backoff logic.
00:08:00 · SEP 13, 2026
Hızlı yanıt
429, planınızın dakika başına istek tavanının izin verdiğinden daha hızlı istek gönderdiğiniz anlamına gelir - kredilerle veya günlük kotayla ilgisi yoktur. Yanıt bir Retry-After başlığı içeriyorsa, tam olarak o kadar bekleyin. İçermiyorsa, jitter ile üstel geri çekilme kullanın ve aynı anda kaç isteğinizin devam ettiğini ayrıca sınırlayın.Hız sınırı ile kota karşılaştırması
Bunlar sık sık karıştırılan iki farklı kısıtlamadır:
- Kota - daha uzun bir pencerede (örneğin bir gün) izin verilen toplam istek sayısı. Tükenmesi, saatler sonrasında olabilecek bir sıfırlamayı beklemek anlamına gelir.
- Hız sınırı - kısa bir pencerede (örneğin bir dakika) izin verilen istek sayısı. Buna takılmak, saatler değil, saniyeler ila bir dakika yavaşlamak anlamına gelir.
Perde arkasında, çoğu API hız sınırlamasını ya bir token kovası (sabit bir hızda istek "token"ları biriktirir ve istek başına bir tane harcarsınız, kısa patlamalara izin verir) ya da bir sabit/kayan pencere sayacı (takvim dakikası başına sabit bir tavan, sınırda sıfırlanır) ile uygular. Belirli bir API'nin hangisini kullandığı, trafiğinizin ne kadar patlamalı olabileceğini güvenle değiştirir - bir token kovası, sabit bir pencereden daha iyi kısa bir sıçramaya tolerans gösterir.
HTTP standardı: RFC 6585 ve Retry-After
429 Too Many Requests, sağlayıcıya özgü bir efsane değil - standart bir HTTP durum kodu olarak resmi olarak RFC 6585'te (Nisan 2012) tanımlanmıştır. RFC 9110'a göre, uyumlu bir sunucu bir 429 (veya 503) yanıtına iki formdan birinde bir Retry-After başlığı ekleyebilir:
- Gecikme saniyesi formu - bir tam sayı, örneğin
Retry-After: 120, 120 saniye beklemek anlamına gelir. - HTTP-tarih formu - mutlak bir zaman damgası, örneğin
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT.
Mevcut olduğunda, bu başlık yetkilidir - sunucu size isteklerinizi tekrar ne zaman kabul edeceğini tam olarak söylüyor. Bunun üzerine kendi üstel geri çekilmenizi katmanlamayın; bu yalnızca kurtarmanızı daha da geciktirir. Yalnızca başlık yoksa geri çekilmeye başvurun.
GetYouTubeTranscript'in hız sınırları
| Plan | Hız sınırı |
|---|---|
| Ücretsiz | 60 istek/dk |
| Aylık ($5/ay) | 200 istek/dk |
| Yıllık ($4,50/ay) | 300 istek/dk |
Bu gerçekte nasıl uygulanıyor
Retry-After başlığı göndermiyor, bu yüzden bu API'den gelen herhangi bir 429'u, orada olmayan bir başlığı ayrıştırmak yerine aşağıdaki kod örneğini kullanarak "en fazla ~60 saniye bekleyin ve geri çekilme ile yeniden deneyin" olarak ele alın.429'ları doğru şekilde ele alma
Doğru işlem sırası: önce Retry-After'ı kontrol edin ve yalnızca eksikse jitter ile üstel geri çekilmeye başvurun. Jitter (bekleme süresini biraz rastgeleleştirmek) önemlidir çünkü birçok istemci aynı anda bir sınıra takıldığında ve hepsi aynı programda yeniden denediğinde, senkronize olurlar ve aynı sınırı hemen tekrar tetikleyen bir "kalabalık hücumu" yaratırlar.
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")Hız ile eşzamanlılık - farklı bir sorun
Dakika başına istek tavanı ile devam eden eşzamanlılık tavanı aynı şey değildir. Promise.all ile aynı anda 50 istek ateşlemek, dakika için toplamınız bütçenin çok altında olsa bile bir 429'a takılabilir, çünkü sunucu (veya önündeki bir proxy) eşzamanlı bağlantıları da sınırlayabilir. Birçok videoyu toplu işlerken, eşzamanlılığı hız sınırı geri çekilmenizden bağımsız olarak sınırlayın:
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)))
);Sürekli yüksek hacimli batch'ler için, plan katmanını yükseltmek dakika başına istek tavanını doğrudan yükseltir - API dokümanlarındaki fiyatlandırmaya bakın veya panelden 100 ücretsiz krediyle başlayın.
Hız sınırı SSS
Bir hız sınırı ile bir kota arasındaki fark nedir?
Bir kota, bir dönem üzerindeki (örneğin günlük) toplam kullanımı sınırlar. Bir hız sınırı, günlük toplam kullanımınızdan bağımsız olarak, birim zaman başına (örneğin dakika başına) kaç istek yapabileceğinizi sınırlar - günlük kotanızın hâlâ çok altındayken bir hız sınırına takılabilirsiniz. Kota tarafı için YouTube API kota rehberimize bakın.
429 yanıtı ne anlama gelir?
429 Too Many Requests, 2012'de RFC 6585'te resmi olarak tanımlandı. Planınız için pencere başına istek sınırını aştığınız anlamına gelir - isteğinizin geçersiz olduğu veya kredinizin bittiği değil, yavaşlayıp yeniden deneme sinyalidir.
Retry-After başlığı nedir ve her zaman ona güvenmeli miyim?
RFC 9110'a göre, bir sunucu bir 429 veya 503 yanıtına iki formdan birinde bir Retry-After başlığı ekleyebilir: bir tam sayı saniye (Retry-After: 120) veya mutlak bir HTTP-tarihi. Mevcutsa, bunun üzerine kendi geri çekilmenizi katmanlamak yerine tam olarak buna uyun - sunucu size ne zaman yeniden deneyeceğiniz konusunda yetkili bir yanıt vermiştir.
GetYouTubeTranscript'in hız sınırı nedir ve bir Retry-After başlığı gönderiyor mu?
API anahtarı başına sabit 1 dakikalık bir pencere (kayan bir pencere değil) olarak uygulanan, ücretsiz planda dakikada 60 istek, aylık planda dakikada 200 istek ve yıllık planda dakikada 300 istek. Şu anda 429'larda bir Retry-After başlığı göndermiyor, bu yüzden bir tane bekleyeceğinize kendi geri çekilmenizi uygulayın (aşağıdaki koda bakın) - pencere kayan değil sabit olduğu için, bekleme en fazla mevcut dakikanın kalanı kadardır.
Bir 429 kredi tüketir mi?
Hayır - hız sınırlı bir istek asla ücretlendirilmez. Yalnızca başarılı istekler kredi tüketir.
Daha fazla verim almak için birden çok API anahtarı açmalı mıyım?
Hayır - bu genellikle bir sağlayıcının adil kullanım şartlarını ihlal eder ve özellikle GetYouTubeTranscript'te, hız sınırlaması zaten API anahtarı başına uygulanır, ancak krediler ve hesap durumu kaç anahtar oluşturduğunuzdan bağımsız olarak hesap düzeyinde takip edilir. Daha fazla verime ihtiyacınız varsa, bunun yerine dakika başına istek tavanını doğrudan yükselten plan katmanını yükseltin.
Dakika başına istek sınırının altındayken isteklerim neden başarısız oluyor?
Bu genellikle bir hız sorunu değil, bir eşzamanlılık sorunudur - 50 isteği paralel ateşlemek, dakika için toplamınız bütçe dahilinde olsa bile bir sunucuyu bunaltabilir. Dakika başına kaç istek gönderdiğinizden ayrı olarak, aynı anda kaç isteğin devam ettiğini sınırlamak için bir eşzamanlılık sınırlayıcısı (Node'da p-limit veya Python'da bir semafor gibi) kullanın.
İlgili
- YouTube API Quota Exceeded: Causes and Fixes
- YouTube Transcript MCP Server: Setup Guide for Claude and Other AI Tools
- YouTube Transcripts in n8n: HTTP Request Workflow Guide
- GetYouTubeTranscript ve TranscriptAPI karşılaştırması
- GetYouTubeTranscript ve youtubetotranscript.com karşılaştırması
- GetYouTubeTranscript ve youtube-transcript.io karşılaştırması