youtube-transcript-api geblokkeerd door YouTube? 4 fixes die werken

De fout: lokaal prima, in productie geblokkeerd

De Python-library youtube-transcript-api is verreweg de populairste manier om YouTube-transcripts programmatisch op te halen. Op je eigen machine werkt hij meestal vlekkeloos. Maar zodra je code op een cloudserver draait, beginnen de verzoeken te falen met excepties als IpBlocked, RequestBlocked of TooManyRequests — vaak met een melding die erop wijst dat YouTube je IP-adres blokkeert.

Hetzelfde overkomt elke aanpak die op scraping leunt: transcript-packages voor Node.js, ondertitels trekken met yt-dlp en zelfgebouwde scrapers lopen allemaal tegen dezelfde muur aan. De trigger is niet je code — het is de plek waar je verzoeken vandaan komen.

Draait je workload op AWS Lambda, Google Cloud Run, Vercel, Railway, Fly.io of een willekeurige VPS, dan ziet YouTube een datacenter-IP-adres. Die IP-reeksen zijn publiek bekend, worden massaal misbruikt door bots en gaan er in bulk uit. Residentiële verbindingen (zoals je wifi thuis) worden zelden geblokkeerd — daarom is "het werkt op mijn machine" hier letterlijk waar.

Waarom YouTube deze verzoeken blokkeert

YouTube-transcripts worden geserveerd door een intern, niet-geauthenticeerd endpoint dat nooit bedoeld is geweest voor gebruik door derden. Er is geen officiële publieke API om transcripts van willekeurige video's op te halen: het captions-endpoint van de officiële Data API vereist OAuth-toestemming van de eigenaar van de video, dus dat werkt alleen voor je eigen video's.

Omdat dat interne endpoint gratis en onbeveiligd is, wordt het platgelopen door AI-bedrijven, SEO-tools en scrapers. YouTube reageert op de enige manier die het heeft — agressieve rate limiting, het en bloc blokkeren van datacenter-IP-reeksen, en af en toe een wijziging aan het endpoint waardoor scraping-libraries van de ene op de andere dag stukgaan.

Elke zelfgehoste oplossing zit daarmee in een permanent kat-en-muisspel. De vier fixes hieronder staan op volgorde, van het meeste zelf bouwen tot het meest uit handen geven.

Fix 1: verzoeken via residentiële proxy's routeren

De standaard-doe-het-zelfoplossing is om je verzoeken via roterende residentiële proxy's te routeren, zodat YouTube gewone huishoudelijke IP-adressen ziet in plaats van je server. Recente versies van youtube-transcript-api ondersteunen dit rechtstreeks: geef bij het aanmaken van de client een proxyconfiguratie mee (de library heeft een WebshareProxyConfig-helper, of gebruik GenericProxyConfig met een willekeurige HTTP- of SOCKS-proxy).

Het werkt, maar het kost wat. Bandbreedte via residentiële proxy's is duur (al gauw een paar dollar per GB), de kwaliteit verschilt enorm per aanbieder, en je haalt er een nieuwe faalmodus mee binnen: als een proxy-IP midden in een verzoek geblokkeerd wordt, heb je retry-logica, health checks en failover tussen aanbieders nodig. Bij lage volumes is het bovendien vaak de traagste optie, omdat elk verzoek een extra hop door het proxynetwerk maakt.

Kies hiervoor als je volledige controle wilt, engineeringtijd hebt om het te onderhouden, en je volume hoog genoeg is om de opzet te rechtvaardigen.

Fix 2: de fetcher op een residentiële verbinding draaien

Een simpelere variant: draai het stuk van je pipeline dat transcripts ophaalt op een plek met een residentieel IP — een Raspberry Pi thuis, een machine op kantoor of een goedkope mini-pc — en laat die de resultaten via een queue of webhook naar je cloudinfrastructuur duwen.

Zo vermijd je proxykosten volledig, en voor kleine, persoonlijke workloads (video's transcriberen voor je eigen aantekeningen of een kleine nieuwsbrief) werkt het verrassend goed. De nadelen liggen voor de hand: het is een fysiek single point of failure, het schaalt niet, en het is een ongemakkelijke architectuur voor een productieproduct.

Fix 3: agressief cachen en netjes backoffen

Welke ophaalmethode je ook kiest, twee gewoonten drukken het aantal blokkades enorm. Ten eerste: cache elk transcript dat je ophaalt. Transcripts veranderen vrijwel nooit, dus er is geen enkele reden om dezelfde video twee keer op te halen. Eén simpele databasetabel met het video-ID als sleutel haalt het gros van je herhaalverkeer weg.

Ten tweede: behandel een blokkade als een signaal, niet als een fout om meteen opnieuw te proberen. Exponentiële backoff met jitter (wacht 1s, dan 2s, 4s, 8s...) houdt je onder de radar. Het endpoint blijven bestoken na een blokkade is de snelste manier om je hele IP-reeks te laten bannen.

Let wel: dit is verzachting, geen oplossing — op een datacenter-IP kan zelfs je allereerste verzoek al geblokkeerd worden. Combineer het met een van de drie andere fixes.

Fix 4: een gehoste transcript-API gebruiken (geen infra te onderhouden)

De beheerde optie: laat een dienst die het IP-probleem al heeft opgelost de transcripts voor je ophalen. ParseJet biedt één endpoint — POST /v1/parse/youtube met een video-URL — en geeft het volledige transcript terug, met de videotitel, het kanaal en de duur als JSON. De blokkades, het proxybeheer en de wijzigingen aan het endpoint worden server-side afgehandeld, dus jouw code is drie regels en blijft drie regels.

Migreren vanaf youtube-transcript-api kost een paar minuten: vervang de library-aanroep door één HTTP POST (werkt vanuit Python, Node.js of alles wat HTTP spreekt — inclusief serverless functies, precies waar de library-aanpak het snelst geblokkeerd wordt). Vraag een specifieke ondertiteltaal aan met de parameter language.

De gratis laag bevat 300 credits per maand (een YouTube-transcript kost 5 credits, dus 60 video's) en betaalde abonnementen beginnen bij $19/maand. Voor de meeste producten is dat goedkoper dan de bandbreedte van residentiële proxy's plus de engineeringtijd om het draaiend te houden.

Welke fix moet je kiezen?

Hobbyproject, laag volume, technisch onderlegd: fix 2 (een machine met een residentieel IP) is gratis en betrouwbaar genoeg.

Hoog volume met eigen infra-engineers: fix 1 (roterende residentiële proxy's) geeft je de meeste controle — reken op proxykosten en doorlopend onderhoud.

Productie-app, agent of RAG-pipeline waarin transcripts een feature zijn en niet je kernbusiness: fix 4 (gehoste API) — één HTTP-call, geen kat-en-muisspel. Leg er in alle gevallen fix 3 (cachen plus backoff) overheen.