JAV Metadata API: One Endpoint Instead of Five Scrapers

If you want JAV metadata in your app, here’s the path everyone walks. You find a source, write a scraper, the scraper breaks, you write another for a second source to cover the gaps, and six months later you’re maintaining five brittle integrations just to get a title, a release date, and a cover image.

There is no public, stable JAV metadata API out there. There never was. javinfo is one. That’s the entire reason it exists.

Why a “JAV metadata API” is so hard to find

The data is real and well-structured. The access is the problem. Every source you’d reach for is a website with defenses, not an API with a contract:

• DMM / FANZA holds most of the catalog and geo-blocks most of the planet. There’s an affiliate API, but the docs are Japanese-only and sit behind the same block.
• JavDB has no official API at all, just community scrapers wearing the name, most of them needing FlareSolverr to get past Cloudflare.
• JavBus, JavLibrary, R18 are the same story: self-hosted scrapers and Docker containers, parsers tied to HTML that changes without notice.

So the “API” you find on GitHub is always a scraper, and a scraper inherits every problem the source site has. A class rename breaks your parser with no changelog and no warning. Cloudflare challenges and region blocks mean you also run a headless-browser bypass and a proxy. And because each source returns a different shape, covering gaps means normalizing three or four schemas yourself.

You don’t maintain one integration. You maintain a scraper, a bypass, a proxy, and a pager for 2am.

What javinfo does instead

One endpoint. Send a code, get one normalized result, the same field shape no matter which source answered.

curl -X POST 'https://javinfo-search.p.rapidapi.com/search' \
  -H 'Content-Type: application/json' \
  -H 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  -H 'X-RapidAPI-Host: javinfo-search.p.rapidapi.com' \
  -d '{ "q": "SSIS-001" }'

{
  "result": {
    "q": "SSIS-001",
    "source": "r18",
    "video": {
      "dvdId": "SSIS-001",
      "titleEn": "Newcomer NO.1 STYLE ...",
      "releaseDate": "2020-07-07",
      "runtimeMins": 120,
      "makers": ["S1 NO.1 STYLE"],
      "actresses": [{ "name": "Example Actress", "image": "https://pics.dmm.co.jp/..." }]
    }
  },
  "latencyMs": 142,
  "cached": false
}

Every provider maps onto the same base video shape: dvdId, titleEn/titleJa, releaseDate, runtimeMins, makers, label, series, actresses, jacketFullUrl, and more. You read result.video.* the same way across sources. We run the scraping, the Cloudflare fights, and the geo-block workarounds so you don’t. This is the provider-agnostic design the whole thing is built on.

The providers

Let javinfo pick the first match, or pin a source with providers:

• r18 returns bilingual metadata (title, cast, maker, label, series, covers) plus actress profile images and sample/gallery URLs. Available on every tier.
• javdb adds an extra.downloadLinks array with magnet and download links, the thing the scrapers fight for. Pro.
• missav adds an extra.streams object with HLS playlist URLs (.m3u8) plus per-resolution variants. Pro.
• javlibrary, javdatabase are coming soon.

On a miss, or if every upstream times out, you get a 504, which usually just means the code isn’t indexed. Responses are cached server-side, so repeat lookups are fast.

Start

Auth, rate limits, and plans live on RapidAPI. The free tier gives you r18 metadata at 500 requests a day; Pro adds the javdb and missav providers, their download and stream links, and 1,000 requests a day. No Docker, no FlareSolverr, no Japanese VPN, no cookie to refresh. You can be running in a minute.