video-scraping-apis: a directory of 979 hosted video API listings

A README with a folder of links, not a package

The repository describes itself as a collection of APIs for scraping video metadata, engagement stats and public video data across multiple platforms, and the README opens by calling it the largest collection of video scraping APIs on GitHub with 979 ready to use APIs for extracting video data, downloading videos, scraping metadata and more.

What the file tree shows is a documentation project. The top level holds a .github directory, a FOLLOW_CREATOR.md file, the README, a settings directory and a single content directory named videos-apis-979. There is no src directory, no package manifest in the tree, no test suite and no build configuration. The language badge says JavaScript, but the repository does not contain a JavaScript library that you add to a project.

That distinction is the whole thing to understand before reading any of the listings. There is nothing to install and no import statement to write. The Getting Started section is four steps, and they are all human actions: browse the APIs in the videos-apis-979 directory, choose an API that fits the need, integrate the API endpoint in your application, and build. The repository is a shortcut through the discovery problem, not a dependency in your build.

The practical consequence is that the quality bar sits entirely with the service you pick. The repository cannot tell you whether an endpoint is accurate, fast or still alive next month, and its own numbers are marketing claims rather than measurements.

Each listing is a pointer to somebody else's hosted endpoint

The README describes what every API page contains, and the list is what tells you what you are actually buying. Each entry includes detailed descriptions, usage examples, integration guides, pricing information and support resources.

That is a good template for a marketplace listing, and it also shows the division of labour. The repository describes the service; the service performs the work. The use case list in the README spans video downloads from YouTube, TikTok, Instagram and Facebook, metadata extraction covering titles, descriptions, thumbnails, durations, view counts and engagement metrics, transcript and subtitle generation, cross platform video search, analytics, playlist extraction, comment and interaction scraping, and audio extraction with MP3 conversion. The platform specific section names channel scrapers and comment collectors for YouTube, video downloaders and hashtag analyzers for TikTok, post and story extractors for Instagram, video metadata extractors for Facebook, scrapers and downloaders for Vimeo, and stream recorders for Twitch.

A hundred and thirty words of that list is what an adopter is really choosing between, and two of the entries deserve attention. Watermark-free downloads and bulk video processing are the two capabilities most likely to sit at the edge of what a platform's terms of service allow, and the README says each API is production-ready and that you can avoid building scrapers from scratch or maintaining complex infrastructure.

The repository does not state which platform each listed API targets, how it authenticates, or what its failure modes are. The Getting Started steps push you to the provider's own documentation for those answers, which is the correct place for them, but it means the list is a lead, not a decision.

The featured block points at one marketplace

One section of the README is a promotional block for APIMesa, which is described as a pay per call API marketplace with 150 or more live APIs for AI, scraping, data, SEO, lead generation, media and developer utilities, with one API key, clear per call credit pricing and a live playground for every API. The block is placed near the top of the README, between the badges and the statistics table, and it is marked in the source as a featured section.

This is worth naming plainly, because it tells you how the list relates to the services. A directory of API listings and a single marketplace that hosts many of those APIs are two different things, and a reader who assumes the listings are independent providers will misread the pricing and the dependency. If most of the 979 entries resolve to the same marketplace, then the choice you are making is between a listing and one vendor behind it, with one key and one billing relationship.

The README continues in the same commercial direction. There is a section inviting readers to join a Skool community about vibe coding, with a linked image and a call to action button, and a FOLLOW_CREATOR.md file sits at the top of the repository. The star history chart is also embedded.

None of that is a reason to skip the list, but it is context for how to read it. Treat the catalogue as a lead generation document, check the provider behind any entry you are considering, and price the per call model against the volume you actually need.

The statistics in the README do not match the repository

The badges at the top claim APIs 979, category Video Scraping, status Active and updated Daily. The collection statistics table further down repeats the total of 979, names the category, and gives a last updated date of 1/27/2026.

The repository itself was pushed to on 2026-10-20 and is not archived, and the file tree shows a single content directory with the 979 listings inside it. So the content is being touched far more recently than the date printed in the statistics table, which means the table is either a manual field that is not refreshed or a snapshot of a different measurement. The daily update badge is not something the file tree can confirm either.

The number 979 is at least self consistent: it appears in the headline, in the badge, in the statistics table and in the directory name videos-apis-979. What is not verifiable from the repository is how the count is defined. Is it one listing per endpoint, or per provider, or per platform per capability, and are near duplicate listings of the same service counted once or several times? The README does not say, so the headline figure should be read as an inventory size rather than as a count of distinct capabilities.

The same applies to the active status badge. Nothing in the repository records whether a given listing still resolves, and there is no GitHub release history to inspect, so the only per API signal is whether the endpoint answers.

No licence, no code, and no install step to fall back on

The limits of this repository are structural rather than fixable, and an adopter should plan around them.

First, there is no licence. The project does not name one in the README, and the tree does not include a LICENSE file, so there is no stated grant for reusing the documentation text, the structure or the listings. For a personal reference list that hardly matters. If you want to reuse the collection inside a company wiki, a course or a product, you have no documented permission to do so.

Second, there is nothing to run. There is no client library, no rate limiter, no retry logic, no response parsing and no error handling, because all of that belongs to the hosted services. Every integration you write is yours to maintain, and every provider is a separate dependency with its own authentication scheme, its own quota and its own breaking changes.

Third, there is no cost control and no abstraction. With 979 candidate endpoints, the temptation is to call several of them for the same job, and each one bills per call. The README offers per call credit pricing through the featured marketplace but no way to compare the cost of a metadata lookup against a transcript generation, and no way to estimate the monthly bill of a bulk job before you run it.

The honest framing is that this is a discovery aid. It shortens the search for a provider, and it hands you pricing and support links, but it adds no capability you would otherwise have to write yourself beyond the search.

A hosted proxy or a scraper you own

The real alternative to a paid endpoint is building the retrieval yourself, and the difference in approach is worth setting out before you pick.

A hosted API puts its own infrastructure between you and the platform. The provider deals with the parts that break: page structure changes, rate limits, signature and token handling, and the per platform quirks of video and metadata endpoints. You send a request and receive a payload, and the ongoing cost is a per call fee. In exchange, your data transits a third party, your requests carry that provider's credentials rather than your own, and your dependence is on a service whose terms you did not write and whose price can change.

Doing it yourself inverts that. You keep the credentials, the data never leaves your infrastructure, and the only dependency is the platform itself, which you can read the terms of directly. The cost is engineering time and the fact that platforms change their internals, so your scraper needs maintenance that the provider was doing for you. The README frames this as the problem the collection solves, with no need to build scrapers from scratch or maintain complex infrastructure, and for a one off project that trade is usually worth taking.

A middle path sits in between and is what many teams end up with: a hosted endpoint for the awkward platforms and direct access for the one that matters most, with a small abstraction of your own so the provider can be swapped later. The catalogue is a reasonable place to find candidates for the first half of that.

What to check before you build on a link

The repository is not archived, the last push was on 2026-10-20, and there are no GitHub releases, so there is no version to pin and no changelog to read. What you can rely on is that the listings are being touched, and what you cannot rely on is that any given listing is accurate.

So the verification work belongs at the provider. For any entry you plan to depend on, read its own documentation for the request format, the authentication method, the price per call, the rate limit and the terms of use, and check whether the response shape is stable or changes without notice. If the entry covers bulk downloads from a platform, read the platform's terms first, because that is the part of the list where a technical decision becomes a legal one.

Two smaller checks are cheap. Ask what the provider does when a video is private, deleted or region blocked, since a scraper that silently returns nothing is worse than one that errors. And confirm that the endpoint can be called from your own infrastructure, because some services only work from a browser session and are of no use from a server.

The concrete starting point is the videos-apis-979 directory itself: pick the platform and the data you need, take three candidates, and compare their pricing and payload shape directly rather than trusting the summary in the listing.

Editorial conclusion

video-scraping-apis fits a developer who wants to compare hosted video data providers quickly and is comfortable wiring up a third party endpoint with per call billing, and it does not fit a team that needs a pinned, licensed dependency or a self hosted pipeline. Before you build on any entry, read the provider's own documentation for its pricing, its terms and its uptime, because the repository is a pointer to those and not a substitute for them.

Frequently asked questions

Official sources

1. cporter202/video-scraping-apis on GitHub
2. Issues
3. README