Best Video Download APIs in 2026: YouTube, TikTok, X

The tested guide to getting the actual video file behind a YouTube, TikTok, Instagram, X or Facebook link from your own code in 2026, with live timings, real prices and the rights questions answered.

There is no official "download" endpoint for YouTube, TikTok or Instagram videos you do not own. Every video download API on the market, from a weekend RapidAPI listing to a managed service with an MCP server, does the same thing underneath: it reproduces what a web or mobile player does, asks the platform for the media streams, and hands you the result. The open-source tool most of them build on, yt-dlp, has more than 205,000 GitHub stars, and the version we tested ships 1,752 extractors, one for nearly every site that plays video.

But here is the problem: what works on your laptop fails on your server. Run yt-dlp from a home connection and a YouTube video lands in seconds. Run the same command from a cloud server and YouTube answers with its "Sign in to confirm you're not a bot" check, an error so common that yt-dlp keeps the report pinned as issue #10128 since June 2024. TikTok refuses many datacenter addresses outright, Instagram, Reddit and Vimeo increasingly want a signed-in session, and YouTube now asks clients to solve JavaScript challenges and carry proof-of-origin tokens before it serves a format URL. The gap between "it worked in my terminal" and "it works in production for every user" is where developers lose weeks.

This guide closes that gap. We ran live downloads of nine videos on seven platforms on 5 November 2026, once through a managed API from its servers and once with plain yt-dlp from a home connection, and we read the pricing pages and terms of every serious option. You get a scored ranking of six ways to download video by API, the first-principles reasons each one works or breaks, the cost per 1,000 videos for each, the architecture that survives two-hour videos and 120-second proxy limits, and a plain reading of what YouTube's own terms allow.

We build Suprsonic, a unified API whose video download capability is one of the options ranked here, so read our scores with that in mind: we score it on the same evidence as everything else, and we say where it fails.

Contents

1. The Assessment: Six Ways to Download Video by API, Ranked
2. Why There Is No Download Button in Any Official API
3. What Changed on YouTube in 2025 and 2026
4. Our Benchmark: Nine Videos, Two Routes, One Morning
5. Official Routes for Video You Own
6. Profile: Suprsonic
7. Profile: Self-Hosted yt-dlp
8. Profile: Vid Kraken
9. Profile: Apify Actors
10. Profile: Cobalt
11. Other Options We Could Not Score
12. The Cost of 1,000 Downloads
13. Architecture: Jobs, Timeouts and Links That Expire
14. Rights, Terms and What You May Actually Do
15. Giving an AI Agent a Video Download Tool
16. How to Choose

---

1. The Assessment: Six Ways to Download Video by API, Ranked

The table below scores the six options we could verify end to end against five criteria chosen from first principles. A developer asking for a video download API is really asking five questions: will it work from my server, what will a thousand downloads cost, what exactly do I get back, how many sites does it reach, and how much work is it to wire in. Generic criteria such as "features" or "support" tell you nothing here, because every option downloads video; what separates them is where the request comes from and what lands in your hands.

Works from a server (30%) measures whether the option delivers YouTube, TikTok and Instagram videos when the request starts from cloud infrastructure, without you supplying your own proxies or cookies. It carries the most weight because it is the failure that kills production systems. Cost at 1,000 videos (25%) uses each option's public price for 1,000 downloads of a 50 MB video, roughly five minutes of 720p. What you get back (20%) separates a hosted file with a stable link from a temporary stream URL that only works from the address that asked for it. Coverage (15%) counts the sites it reaches. Integration effort (10%) scores how much code and operations stand between you and a first working download.

Each final score is the weighted average of the five scores, rounded to one decimal place, and the rows are ordered from highest to lowest. Two things stand out once you read across rather than down. First, no option wins every column: the cheapest per video (Apify's URL extractor) hands you links that expire and are bound to the address that requested them, and the broadest coverage (yt-dlp) is the hardest to run from a server. Second, the spread in cost at 1,000 videos runs from about $10 to about $865, a factor of more than 80, for what looks like the same job. The rest of this guide explains where that spread comes from, because once you understand it you can predict which option fits your workload without trusting anyone's table, including ours.

Why this matters in practice: the option you pick decides what fails at 2 a.m. A URL extractor fails when your downloader runs from a different machine than the one that extracted. A self-hosted yt-dlp fails the day YouTube changes its player, until you update. A managed API fails when a site starts demanding a login, as Vimeo and Reddit did. How to apply this: decide first whether you need the file or only metadata, then whether you can run residential egress yourself, and only then compare prices.

2. Why There Is No Download Button in Any Official API

Video platforms earn money while you watch on their surface, with their ads, their recommendations and their measurement around the video. A file that leaves the platform takes all of that with it, so the platforms built their developer APIs to describe videos, not to hand them over. The YouTube Data API v3 lets you list, insert, update and delete videos, read titles, durations, statistics and comments, but its video resource has no operation that returns the media. TikTok's Display API returns video metadata for a signed-in creator, and its Content Posting API only publishes to an account. The absence is deliberate, and YouTube's API Developer Policies spell it out: API clients must not "download, import, backup, cache, or store copies of YouTube audiovisual content without YouTube's prior written approval".

So every download API is an extractor, not an integration. It loads the watch page or calls the private endpoints the platform's own apps use, reads the list of available formats, and fetches the streams. On YouTube those streams arrive as separate pieces: when we asked yt-dlp for the classic 19-second "Me at the zoo" video on 5 November 2026, the old combined 360p MP4 format was no longer offered at all, and the best formats came back as a video-only stream and an audio-only stream that FFmpeg has to merge. That is why every serious download tool depends on FFmpeg, and why a download is CPU work as well as bandwidth.

The format URLs themselves carry the platform's conditions. The YouTube stream URL we extracted pointed at a googlevideo.com host and carried an expire parameter about six hours out and an ip parameter holding the address that asked. A URL extracted on one machine is therefore a poor thing to pass to another: the second machine is a different address, and after six hours the link is dead anyway. This single detail explains why "extract the URL, download it later" architectures break in production, and why the options that score highest on what you get back are the ones that fetch the file themselves and give you a link to their own copy.

Why this matters: the shape of what comes back decides whether your pipeline survives its first move to a second machine. How to apply this: treat any API that returns "the download URL" with suspicion until you know whether it is the platform's stream URL (bound and expiring) or the provider's own stored copy (portable for as long as they keep it). If you only need the title, duration, thumbnail and formats, a metadata call is cheaper and less fragile than a download, and the same extractors answer it in a second or two. For transcription work, downloading audio only (an M4A or MP3) cuts the file to a fraction of the video and is all a speech-to-text API needs, which we covered in our guide to speech-to-text APIs for AI agents.

The broader lesson is one we keep returning to on this blog: the capabilities a language model lacks are exactly the ones that touch the outside world through somebody else's surface, as we argued in what LLMs cannot do. Video download is an extreme case, because the surface owner actively prefers that you not do it. That is the context for everything that follows, from YouTube's defences to the rights section near the end.

3. What Changed on YouTube in 2025 and 2026

YouTube is the hardest platform to download from and the one most people need, so its defences shape the whole market. Three layers matter now, and each one moved the cost of a working downloader up. The first is address reputation. YouTube judges the network a request comes from, and datacenter ranges belonging to cloud providers are treated as likely bots. The visible symptom is the "Sign in to confirm you're not a bot" response, collected in yt-dlp's pinned issue #10128, which maintainers label an external site issue rather than a yt-dlp bug: there is nothing in the code to fix, because the decision is made about the address. In our own production, a plain yt-dlp request from our cloud servers ends on that check within a second or two, while the identical command on a home connection succeeds.

The second layer is proof-of-origin tokens. YouTube now expects many of its clients to present a PO token that attests the request came from a genuine player. yt-dlp's PO Token Guide says that without one, requests for the affected clients' format URLs may return HTTP Error 403, that tokens are bound to the video, and that the web, mweb, android and ios clients need them while some other clients do not (with their own trade-offs, such as DRM-protected formats). The guide no longer recommends extracting tokens by hand and points to plugins that generate them, which adds another moving part to a self-hosted stack.

The third layer is JavaScript challenges. yt-dlp's EJS wiki page states plainly that "yt-dlp needs to solve JavaScript challenges presented by YouTube", and the project's README lists its yt-dlp-ejs component as required for full YouTube support. That component needs a JavaScript runtime: Deno is recommended and enabled by default from version 2.3.0, Node.js 22 can be enabled by hand, and Bun is deprecated. A Python tool that once needed only Python and FFmpeg now needs a second runtime on every machine that downloads from YouTube.

Why this matters: each layer raises the fixed cost of running your own downloader without raising the price of a managed one, which is why the market has tilted toward services. A team that self-hosts now maintains egress addresses YouTube accepts, a token provider, a JavaScript runtime, FFmpeg, and a yt-dlp that updates often (the latest release at the time of writing is 2026.10.26). How to apply this: if your downloads start from a cloud server, budget for residential or consumer-grade egress from day one rather than discovering the bot check after launch; if they start from end-user devices, a client-side tool may avoid the problem entirely, because each user's own address is the one YouTube judges.

The other platforms are moving in the same direction more quietly. In our test on 5 November, yt-dlp 2026.08.19 reported that Vimeo's web client "only works when logged-in" and that Reddit "account authentication is required" for public posts that downloaded anonymously not long ago, and an Instagram reel failed anonymously from our home connection. The trend across 2025 and 2026 is clear: anonymous access is shrinking, and the remaining question for each platform is whether a managed service can still serve it from addresses the platform accepts.

4. Our Benchmark: Nine Videos, Two Routes, One Morning

Benchmarks of download services are rare because they cost money and age fast, and most published comparisons are lists copied from other lists. So we ran our own on the morning of 5 November 2026 (UTC): the same public videos through two routes, one after the other. Route one was the Suprsonic API, called from a script and polled with its job ID until it handed over a link to the finished file, which means the time includes the server-side download, the merge and the upload to storage. Route two was yt-dlp 2026.08.19 with FFmpeg and Deno, run on a home fibre connection in Europe and saving a 720p-or-below MP4 to disk. The test videos are public and long-standing, mostly drawn from yt-dlp's own test cases so anyone can repeat the run.

Two caveats keep the numbers honest. A home connection is the best case for yt-dlp, because YouTube and TikTok judge the address and a residential address passes; the same commands from a cloud server would meet the bot check described above, which is exactly the situation a production backend is in. And the two routes measure slightly different things: yt-dlp's time ends with the file on the local disk, while the API's time ends with a link to a stored copy, which the caller still has to fetch. We report both as measured rather than adjusting either.

The pattern is the one first principles predict. On a residential line, plain yt-dlp is fast for YouTube and TikTok because nothing stands between it and the platform, and the API adds the cost of a round trip, a stored copy and a polling loop. Where the platform demands more than an address, the picture flips: the Instagram reel downloaded through the API in 3.1 seconds but failed anonymously from the home connection, and the X video arrived three times faster through the API. Size differences come from format choice, not quality claims: for Big Buck Bunny the API picked a 60-frame-per-second 720p stream (173 MB) where yt-dlp's default selection took a smaller one (102 MB).

The failures matter as much as the successes. Neither route could download a public Vimeo video or a public Reddit post anonymously on 5 November 2026, and both said why in the platform's own terms. For Suprsonic that is a gap in coverage it shares with every extractor that has no signed-in session; if your product depends on Vimeo or Reddit, you need the owner's cooperation (for Vimeo, the API's file links on the account that owns the video) or a session of your own, with the terms questions that brings.

Why this matters: published comparisons rarely say where their requests came from, and that is the variable that decides the result. How to apply this: run the same nine-row test against your own shortlist before you commit, from the machine your production code will run on. It takes under an hour, costs a few dollars at most, and it is the only benchmark that answers your question, because the result depends on the address the request comes from more than on the provider's code. Our script is short: call the download endpoint, poll until a file or an error arrives, record the time and size, and repeat with yt-dlp.

5. Official Routes for Video You Own

Before any extractor, check whether you even need one. A large share of real download needs are about video you or your customer already own: a brand archiving its own uploads, an agency pulling a client's reels for a recap, a creator tool that edits a creator's own clips. For those cases the platforms do offer sanctioned routes, and using them removes both the technical fragility and most of the rights question, because the owner is the one asking.

Instagram's Graph API media object has a media_url field, "the URL for the media", available to a professional account's own media with the instagram_basic or instagram_business_basic permission. Read the caveats in that reference before you depend on it: the field is omitted for videos with copyrighted or licensed audio, even when the user owns the post, and Meta's docs tell you to treat it as optional. The X API's data dictionary describes media objects that "may have multiple display or playback variants", each with a bit rate, a content type such as video/mp4 and a URL, requested through the attachments.media_keys expansion and media.fields. Vimeo's API returns file and download links for videos on the account that owns them, with the video_files scope: per Vimeo's own help article, download links stay valid for 24 hours and play links expire after 24 hours.

Why this matters: an official route is the one that keeps working when extractors break, and it is the cleanest answer to "may we do this?". YouTube is the conspicuous gap: an owner can download their own uploads in YouTube Studio, but there is no API for it, which is why so many legitimate archiving tools still end up using extractors on their own channel's public URLs. How to apply this: if your users connect their own accounts, build on the official route for each platform that has one and keep an extractor only for the platforms that do not, with the user's confirmation that they own or license what they are downloading.

The comparison also clarifies what the commercial download APIs are for. They exist for the cases the official routes leave out: public videos your product needs to process, analyse, transcribe or clip, from accounts you do not control. That is a legitimate need in research, monitoring, accessibility and content tooling, and it is also where the terms questions live, which we take up in section 14.

6. Profile: Suprsonic

Suprsonic is a unified API for AI agents and developers: one key reaches 25 capabilities, from web search and scraping to speech, images and research, and two of them are video. Video Info (1 credit) returns the title, duration, thumbnail and available qualities for a link, and Video Download returns a temporary link to a finished file in MP4, MP3 or M4A at 360p, 480p, 720p, 1080p or the best available. A video download costs 3 credits and an audio download 2, charged once, on the call that hands over the file; a download that fails costs nothing, and so does every check on a job in progress.

The design choice that defines it is that every download is a job. A short clip usually finishes inside the first request, which waits up to 90 seconds and answers with the file. A long one answers status: processing with a job_id and a suggested wait of 20 seconds; sending the same request with that job_id instead of the URL returns the file once it is ready. This is what lets one endpoint handle a 19-second clip and a two-hour livestream recording alike: the service accepts files up to 2 GB and three hours, and the job's state lives in a database, so a dropped connection on your side or a deploy on ours does not lose the download. The finished file sits in storage and the API hands you a pre-signed link valid for one hour.

Behind the endpoint, each download is routed across several sources, cheapest first, with the platform's own verdict ending the attempt early when a video is private, removed or region-blocked, so you are not charged and do not wait for retries that cannot succeed. The breadth comes from the same extractor ecosystem everything else uses, which is why the coverage is wide and why it inherits the same walls: in our benchmark, public Vimeo and Reddit videos failed for want of a signed-in session, exactly as they did for plain yt-dlp.

Pricing - Source:

The price is flat per video rather than per gigabyte, which favours long videos: a one-hour talk and a six-second clip cost the same 3 credits. That is the opposite of the per-GB services and the reason Suprsonic sits in the middle of the cost chart for short clips and near the bottom for long recordings. It is also the only option in this guide that is part of a broader agent toolkit: the same key transcribes the audio you just downloaded, converts files, or researches the topic, and agents reach it through a hosted MCP server as well as REST and SDKs.

Why this matters: a flat price and a job contract remove the two things that usually break first, the bill on long videos and the timeout on slow ones. How to apply this: it is best for products and agents that need files from several platforms without running their own egress, especially when long recordings or audio-for-transcription are part of the workload. Not for: Vimeo or Reddit content today, or teams that need the platform's raw stream URLs to proxy themselves.

7. Profile: Self-Hosted yt-dlp

yt-dlp is the open-source command-line tool and Python library that most of this market runs on. It descends from youtube-dl, is released under the Unlicense and has more than 205,000 GitHub stars, and its supported sites list covers every extractor it includes: 1,752 in the 2026.08.19 release we tested, of which about 1,200 are distinct sites once per-site variants such as playlists and channels are counted together. It selects formats, merges video and audio with FFmpeg, embeds subtitles and metadata, and handles playlists and channels, all from one command or one Python call.

As a library it is the fastest way to a working prototype, and on a residential connection it is also the fastest route in our benchmark for YouTube and TikTok. The cost appears when you move it to a server. You inherit YouTube's three layers of defence (address reputation, PO tokens and JavaScript challenges), so a production deployment needs a JavaScript runtime such as Deno on every worker, a PO token provider plugin, egress through addresses YouTube accepts, and a habit of updating yt-dlp whenever a platform changes, which YouTube in particular does often. The Extractors wiki also notes that YouTube rate-limits guest sessions and accounts, so heavy volume needs pacing as well as addresses.

# Best 720p-or-below video with audio, merged to MP4 (needs FFmpeg; Deno for YouTube)
yt-dlp -f "bv*[height<=720]+ba/b [height<=720]/b" \
  --merge-output-format mp4 \
  -o "%(id)s.%(ext)s" \
  "https://www.youtube.com/watch?v=jNQXAC9IVRw"

The egress is where the money goes. Residential proxy bandwidth from a large provider such as Bright Data lists at $8 per GB, or $4 per GB with its current discount on its pricing page, and every byte of video flows through it. At 50 MB a video, 1,000 downloads move about 50 GB, so the proxy alone costs $200 to $400 per 1,000 videos, before compute, storage or your time. That is why free software ends up as one of the more expensive options at scale, and why self-hosting makes the most sense where the requests can come from addresses that already pass: end-user devices, or a small internal tool on an office connection.

Why this matters: yt-dlp is the ground truth every other option is measured against, so knowing its real running cost tells you what a managed service is worth. How to apply this: it is best for prototypes, internal tools on residential connections, client-side apps where each user downloads from their own address, and teams that need a site no managed service supports. Not for: a cloud backend that must serve YouTube and TikTok reliably without a dedicated person keeping the stack current.

8. Profile: Vid Kraken

Vid Kraken is a managed download service focused on YouTube. Its public page describes a REST API (version 2), an OpenAPI specification, SDKs and an MCP server, and it bills by the gigabyte delivered rather than by the video, with a 20 MB minimum per download. Failed downloads, polling and metadata lookups are free, which is the same principle as Suprsonic's charge-on-success and a sign the service is built for production integrations rather than one-off use.

Pricing - Source:

On the Starter plan, 400 GB covers about 8,000 downloads of a 50 MB video, so the effective price is about $12 per 1,000 videos while you stay inside the allowance, rising to about $25 per 1,000 for the overage at $0.50 per GB. Per-GB billing cuts both ways: short clips are cheap (though the 20 MB minimum means a 2 MB clip is billed as 20 MB), and long recordings scale with their size, so a 1.3 GB two-hour service costs as much as 65 short clips. We used Vid Kraken's free tier during our own development work in October 2026, and it delivered the YouTube files we asked for.

Why this matters: per-GB billing rewards a predictable mix of short videos and punishes long ones. How to apply this: it is best for YouTube-heavy products with predictable volume that fits a monthly allowance. Not for: TikTok, Instagram, X or Facebook, which its page does not list, or workloads dominated by very long videos where per-GB pricing adds up.

9. Profile: Apify Actors

Apify is a marketplace of scrapers ("actors") that run on Apify's own infrastructure and are billed per run, per result or per event. Several actors download video, and they differ more than their names suggest, so we read the pricing pages of two representative ones in full. Both are called through the same Apify API: you start a run with the video URLs as input, wait for it to finish, and read the results from the run's dataset, which makes them asynchronous by nature and a natural fit for batch jobs.

The video-download-crawler actor charges $9.80 per 1,000 videos (about one cent each) plus Apify platform usage, and only charges when at least one downloadable format URL is extracted, so private or deleted videos cost nothing. The crucial detail is in its own description: it "extracts the download URLs only" and "does not download, store, or redistribute video files", and it warns that the URLs are temporary. As section 2 showed, a YouTube stream URL carries the address that requested it and expires within hours, so this actor is excellent for metadata and format discovery and for platforms whose URLs are portable, and a poor fit when you need a durable file.

The youtube-downloader actor takes the other approach and stores the file, billing $17 per GB of downloaded data (falling to $15 at its Gold tier), plus $0.005 per result and $0.01 per run start on the default memory. At 50 MB a video that is about $0.87 per video, or roughly $865 per 1,000, the most expensive option we priced by a wide margin, and it covers YouTube only. The price reflects what is actually expensive in this business: moving bytes through addresses YouTube accepts.

Why this matters: the two actors show the same marketplace pricing the cheap part (finding the URL) and the expensive part (moving the bytes) a hundred times apart. How to apply this: they are best for batch pipelines already built on Apify, metadata and format discovery at a very low price (the URL extractor), and occasional YouTube files where convenience matters more than unit cost. Not for: high-volume file delivery, where per-GB pricing on the storing actor dominates, or any workflow that passes extracted YouTube URLs to a different machine.

10. Profile: Cobalt

Cobalt is an open-source download server with about 45,800 GitHub stars, known for its clean public website and a JSON API. Its source lists 21 supported services, including YouTube, TikTok, Instagram, X, Facebook, Reddit, Vimeo, Twitch, SoundCloud, Bluesky and Pinterest, and it can either redirect to a media URL or tunnel the file through its own server, merging streams as needed. For a developer it is the most "product-shaped" open-source option: one HTTP call in, one file out.

The public instance is not an API for your product. Cobalt's own API documentation says hosted instances such as api.cobalt.tools are "not intended to be used in other projects without explicit permission" and use bot protection, and it recommends running your own instance. Self-hosting is straightforward (Docker Compose, with API_URL as the only required setting), and an instance can require API keys or Cloudflare Turnstile tokens and can load a cookies file for services that need a signed-in session. What self-hosting cannot change is the address problem: your Cobalt instance on a cloud server is judged by YouTube and TikTok exactly as a yt-dlp worker would be.

Why this matters: Cobalt shows that the software is no longer the hard part; the addresses are. How to apply this: it is best for teams that want a self-hosted download service with an API surface rather than a CLI, especially for the non-YouTube platforms it supports. Not for: anyone hoping to call the public instance from production, or YouTube at scale from datacenter addresses without additional egress.

11. Other Options We Could Not Score

A ranking is only as honest as its evidence, so several well-known options sit outside the scored table, either because we could not verify what they return or because they answer a different question. They are still worth knowing, and for some workloads one of them is the right answer. What follows is what we could confirm from their own pages on 5 November 2026, with the gaps named rather than filled in from memory.

Zyla Labs' YouTube MP4 Video Downloader API is a marketplace listing priced by request: its Pro plan lists about €46 a month for 5,000 requests, which is roughly €9 per 1,000, with larger plans up to 100,000 requests and a seven-day trial of up to 50 requests. The listing caps its YouTube downloader endpoint at 4,000 requests a day and two a second, and the page's structured data quotes slightly different plan prices from its visible table, so check the checkout before budgeting. We did not test what it returns (a stored file or a stream URL), which is the question that decides its score, so it stays unscored.

RapidAPI hosts dozens of "social media downloader" and "YouTube media downloader" listings, some with large subscriber counts. Their pricing pages render in the browser only and we could not read verified prices or quotas for any of them, so we name none. The general advice holds: a listing that returns the platform's own stream URLs inherits the expiry and address binding described in section 2, so test the returned link from a different machine before you build on it.

Social media data APIs such as ScrapeCreators (from $47 for 25,000 credits, credits that never expire), EnsembleData (from $100 a month for 1,500 units a day across eight platforms) and Bright Data's social media scrapers ($1.50 per 1,000 records pay as you go) are built for profiles, posts, comments and engagement numbers. Bright Data's YouTube and Vimeo outputs include a video URL field, but none of these pages promises a downloadable file, so treat them as the metadata layer of a pipeline rather than the download layer.

Why this matters: the cheapest-looking price in this market is often a price for something other than the file. How to apply this: for every candidate, ask three questions before comparing prices: does it return a file or a link, if a link, whose copy is it and how long does it live, and which platforms did it actually serve when you tested it from your own server. An option that cannot answer all three is not yet a candidate, whatever its listing says.

12. The Cost of 1,000 Downloads

Prices in this market are quoted in incompatible units: per video, per request, per gigabyte, per result, per run start, per credit. To compare them we priced one workload, 1,000 downloads of a 50 MB video, about five minutes of 720p, using each option's public price as listed on 5 November 2026. For per-GB pricing we multiplied 50 GB by the rate; for per-video or per-credit pricing we multiplied the unit price by 1,000. Where a price covers only a URL, not a file, the chart says so in its label, because it is not the same product.

Three forces explain the spread. The first is bandwidth through accepted addresses, the dominant cost for any option that moves files through residential or consumer egress: at Bright Data's discounted $4 per GB, 50 GB is $200 before a single CPU cycle. Options that bill per GB pass this through directly (Apify's storing actor at $17 per GB), while options that bill per video absorb it into a flat price and win on long videos. The second is what is delivered: extracting a URL costs a fraction of a cent, and the Apify extractor's $9.80 per 1,000 reflects that, but you still have to fetch the bytes from an address the platform accepts within the URL's lifetime. The third is commitment: Vid Kraken's low effective price assumes you use most of a $99 monthly allowance, and Suprsonic's per-video price falls from $0.044 to $0.031 as the plan grows.

The workload shape changes the ranking. For long recordings (a 1.3 GB two-hour service, say), per-GB options cost 26 times what they cost for a 50 MB clip, while a per-video price does not move: on Suprsonic that service is still 3 credits. For very short clips, per-GB pricing looks cheap until a minimum applies (Vid Kraken bills at least 20 MB a download). For audio only, pick an option that downloads audio formats natively: an M4A of a one-hour talk is a small fraction of the video, and Suprsonic bills audio at 2 credits instead of 3.

Why this matters: the same provider can be the cheapest or the most expensive option depending on how long your videos are. How to apply this: compute your own median and 95th-percentile video size from a sample of real inputs, then price each option on both. If the 95th percentile is more than ten times the median, per-video pricing will usually win; if your videos are uniformly short and your volume is steady, a per-GB allowance can be cheaper. And price failure too: every option in our scored table that charges per success (Suprsonic, Vid Kraken, the Apify extractor) costs nothing for a private or deleted video, while a self-hosted proxy bills the bytes of every attempt.

13. Architecture: Jobs, Timeouts and Links That Expire

A video download is the textbook example of a request that outlives an HTTP connection. A two-hour recording can take minutes to fetch and merge even on a fast route, and almost every layer between your user and your code has a clock running. Vercel's functions default to 300 seconds and allow up to 800 on the Pro plan ( Vercel docs); Cloudflare closes a proxied request that has not answered within its 125-second proxy read timeout with error 524; many API gateways and load balancers sit at 60 to 120 seconds. Any design that holds one request open for the whole download will work in testing on short clips and fail in production on the first long one.

The robust pattern is the one HTTP has had a status code for since the beginning: 202 Accepted, which MDN defines as a request "accepted for processing, but processing has not been completed". The client starts a job, receives an identifier, and checks back; the server records the job's state durably, runs the download in a worker, stores the file, and answers the next check with a link. Suprsonic's video endpoint is built this way (with a 200 response carrying status: processing and a job_id), and so are Apify runs and most managed download services.

Four details separate a pattern that works from one that merely looks right. Charge and count on completion, not on start, so a retry or a second check never bills twice; a compare-and-set on the job record is enough. Make the job survive your own deploys: keep its state in a database and let any process that sees a finished worker publish the file, so a restart mid-download does not orphan it. Hand files over through pre-signed links, which AWS describes as granting "time-limited permission to download objects", and choose a lifetime that matches how fast your client fetches (one hour is common; the AWS CLI allows up to seven days). Let a platform's verdict end the job early: when the platform says a video is private, removed or region-blocked, no retry will change that, and a pipeline that keeps trying burns money and time.

On the client side the polling loop is short. The example below starts a download with Suprsonic's API and checks back until the file is ready; the same shape works for any job-based provider.

import time, requests

API = "https://suprsonic.ai/v1/video/download"
HEADERS = {"Authorization": "Bearer omk_your_key_here"}

def download(url: str, quality: str = "720", fmt: str = "mp4") -> dict:
    body = {"url": url, "quality": quality, "format": fmt}
    while True:
        r = requests.post(API, headers=HEADERS, json=body, timeout=150).json()
        if not r ["success"]:
            raise RuntimeError(r ["error"])
        data = r ["data"]
        if data ["status"] == "done":
            return data  # download_url, expires_at, filename, filesize_mb, duration_seconds
        # Still processing: check the same job, never start a second one
        body = {"job_id": data ["job_id"], "quality": quality, "format": fmt}
        time.sleep(data.get("retry_after_seconds", 20))

file = download("https://www.youtube.com/watch?v=jNQXAC9IVRw")
print(file ["filename"], file ["filesize_mb"], "MB, link valid until", file ["expires_at"])

Why this matters: the job pattern is not an optimisation, it is the difference between a feature that works for every video and one that works for short ones. How to apply this: whichever provider you choose, put your own job record in front of it, so your product's state does not depend on the provider's, copy the file into your own storage as soon as the link arrives if you need it beyond the link's lifetime, and keep the original URL and the provider's job ID together so a support question can be answered from your own records. For the file conversions that often follow a download (extracting frames, converting audio, pulling text from a slide deck in a recorded talk), our file conversion API guide covers the next step.

14. Rights, Terms and What You May Actually Do

A technical guide to downloading video that skips the rights question does its readers a disservice, because the rights question is where projects actually get shut down. Two separate sets of rules apply to every download: the platform's terms of service, a contract between you and the platform, and copyright law, which protects the people who made the video regardless of where it is hosted. They overlap but are not the same, and an API provider's own terms usually make clear that compliance with both is the customer's responsibility. Nothing here is legal advice; it is a map of where the lines are drawn so you can ask a lawyer the right question.

YouTube's Terms of Service (effective 15 December 2023 in the English version) say you may not "access, reproduce, download, distribute, transmit, broadcast, display, sell, license, alter, modify or otherwise use any part of the Service or any Content" except as expressly authorized by the Service or with YouTube's prior written permission. Its API Developer Policies add the specific bar on downloading or storing audiovisual content quoted in section 2. YouTube does authorise one download path for creators: an owner can download their own uploads from YouTube Studio as an MP4 at 720p or 360p, up to five times a day per video, or all uploads at once through Google Takeout, per YouTube Help.

Copyright is a separate layer. Downloading a video you have the rights to (your own, a client's with permission, or content under a licence that allows copying such as some Creative Commons licences) is on solid ground. Downloading someone else's work to republish it is not, whatever tool you use. In between sit uses that may qualify as fair use in the United States or as an exception elsewhere (research, criticism, commentary, accessibility), which depend on the purpose, the amount used and the effect on the market for the original, and which courts decide case by case. A product that downloads at scale should assume it will receive takedown requests and have a process for them.

Why this matters: a download feature that ignores rights tends to end with a takedown notice or a suspended account, not a bug report. How to apply this: decide in writing which of these uses your product supports, put that statement in your own terms, ask users to confirm they own or are licensed to process what they submit, keep downloaded files only as long as the job needs them, and honour removal requests quickly. Short-lived files help on both fronts: they reduce storage cost and they keep you closer to "processing" than to "archiving". If your product is an AI agent that acts on a user's instruction, the same principles hold, and the agent's tool descriptions are a good place to state them so the model itself respects them.

15. Giving an AI Agent a Video Download Tool

Agents are now a large share of the callers of download APIs: a research agent transcribing a conference talk, a marketing agent pulling a brand's own reels for a recap, a support agent fetching the video a customer linked to. An agent needs three things from such a tool that a script does not: a description precise enough that the model calls it correctly, an asynchronous contract the model can follow without a human writing the polling loop, and errors written for a reader, so that "this video is private" leads the agent to tell the user instead of retrying forever. We covered how agents discover and call tools in our guide to the 50 best MCP servers for AI agents, and the same rules apply here.

The Model Context Protocol is the simplest way to give an agent this capability without writing the integration yourself. Suprsonic's hosted MCP server at https://suprsonic.ai/v1/mcp exposes video-info and video-download as tools alongside its other capabilities; clients that support MCP sign-in (Claude, ChatGPT, VS Code) connect by signing in, and any other client sends its key as a bearer header. Because the download tool follows the job contract, the model receives status: processing with a job_id and calls the tool again with the ID, the same loop as the Python example above, with nothing for you to write. If you prefer to build your own server around a provider, our guide to building your first MCP server walks through it.

A common pipeline chains three calls: get the video's details, download the audio only, and transcribe it. With one key the whole chain stays inside one API and one bill, and costs 1 credit for the details, 2 for the audio and 3 for a transcription with speaker labels.

# 1. Details and formats (1 credit)
curl -s -X POST https://suprsonic.ai/v1/video/info \
  -H "Authorization: Bearer omk_your_key_here" -H "Content-Type: application/json" \
  -d '{"url": "https://www.youtube.com/watch?v=jNQXAC9IVRw"}'

# 2. Audio only, as M4A (2 credits, charged when the file is handed over)
curl -s -X POST https://suprsonic.ai/v1/video/download \
  -H "Authorization: Bearer omk_your_key_here" -H "Content-Type: application/json" \
  -d '{"url": "https://www.youtube.com/watch?v=jNQXAC9IVRw", "format": "m4a"}'

Why this matters: agents fail differently from scripts. A script that hits a timeout crashes and a developer sees it; an agent that hits a timeout may apologise, retry with a different tool, or invent an answer. A tool with a clear job contract and plain-language errors keeps the agent honest about what happened. How to apply this: whichever provider you wire in, test the agent on a long video, a private video and a removed video before launch, and read the transcript of what the model said to the user in each case. For a wider view of which capabilities agents need beyond video, see our ranking of the top 10 capabilities for your AI agent and the broader top 100 APIs for AI agents.

16. How to Choose

The decision comes down to where your requests start and what you need at the end, and four questions settle it for most teams. Do you own the content? If yes, use the platform's official route where one exists (YouTube Studio or Takeout, Instagram's media_url, X's media variants, Vimeo's download links) and use an extractor only for the gaps. Do you need the file, or only facts about it? If only facts, a metadata call or a URL extractor such as the Apify actor at about one cent a video is the cheapest answer, and a social data API may already cover your platforms.

Where do your requests come from? If they start on users' own devices or a residential connection, self-hosted yt-dlp or Cobalt is free and fast, as our benchmark showed, and the job is mostly keeping the tool updated. If they start on cloud servers, budget for addresses the platforms accept, either by buying residential egress yourself (about $200 per 1,000 50 MB videos at $4 per GB) or by paying a managed service that has solved it. What does your size distribution look like? Short, uniform clips at steady volume favour per-GB allowances like Vid Kraken's; long recordings, audio extraction and mixed platforms favour a flat per-video price like Suprsonic's.

Why this matters: the wrong choice here shows up as a support queue, not a failed test. How to apply this: whatever you choose, run the nine-video test from section 4 from your own production environment before you commit, because the address your requests come from decides more than any feature list. Then build the job pattern from section 13 around it, so your product's behaviour does not depend on how fast one provider answers. If you want a single API that covers video alongside search, scraping, transcription and the rest of an agent's toolkit, Suprsonic starts with a free seven-day trial; its API reference documents every parameter used in this guide, and we cover the neighbouring capabilities in our guides to scraping APIs and data extraction APIs.

The video download market will keep moving, because the platforms keep moving it: each new defence raises the cost of self-hosting and widens the gap between what works on a laptop and what works in production. The durable choices are the ones this guide keeps returning to: know whether you need a file or a fact, know whose address is asking, never let a long download hold a request open, and stay on the right side of the people whose videos you are fetching.

This guide reflects tests and public pricing as of 5 November 2026. Platforms change their defences and providers change their prices often, so verify current details, and re-run your own test, before you commit.