Introduction
What TubeExtract does, what it deliberately does not do, and the one constraint you need to design around before writing any code.
What this is
You give us a YouTube video and a list of columns, each with a name and a plain-English description of what it holds. We read the video’s caption track and return JSON matching those columns. Nothing else about the video is used: no audio, no frames, no on-screen text.
A schema either describes one record per video or many. Ask for many and you get an array, one entry per thing the narration talks about.
Captions only, and why
Speech-to-text and on-screen OCR were both built and then removed. Neither beat the captions YouTube already publishes on videos that have them, and both cost several times the processing time. So the rule is simple: if a video has a caption track, manual or auto-generated, we can read it. If it does not, the job fails and costs you nothing.
no_captions as a normal outcome, not an exception — see videos without captions.The shape of a job
Every extraction is a job. You create one, it is queued, a worker picks it up, and you read the result back. Jobs move through four states and never go backwards.
A typical 25-minute video finishes in twelve to fifteen seconds. Batches of many videos are queued as separate jobs so one slow video never blocks the rest.
What it is bad at
Worth knowing before you build on it, because these are measured limits rather than bugs waiting to be fixed.
A video enumerating forty items will not yield forty rows. Expect good coverage of what is discussed at length, not a complete inventory.
Auto-generated captions transcribe the same name inconsistently, and both spellings can survive as separate rows. Deduplicate on your side if it matters.
When three subjects are discussed back to back with numbers scattered through casual talk, fields can end up attributed to the wrong one. We return an empty result rather than a confident wrong one when this is detected.