L'API JavDB qui n'existe pas

Il n’y a pas d’API JavDB. JavDB n’en a jamais livré. Cherche « javdb api » et tu obtiens un tas de scrapers communautaires portant ce nom, chacun parsant du HTML qui peut casser dès demain.

C’est tout le problème en une phrase. Ça vaut quand même le coup de passer en revue ce qui existe réellement, parce que tu vas tomber sur tout ça.

Vers quoi « javdb api » pointe réellement

Une poignée de dépôts, aucun officiel, tous fragiles :

• javdb-python enveloppe javdatabase.com, même pas javdb.com. L’auteur le dit clairement : les fonctions et la structure HTML ne constituent pas une API stable. Bon pour un script jetable, pas pour quoi que ce soit que tu mets en production.
• javdb-api sur npm est de fait mort. Aucune publication depuis plus d’un an, une poignée de téléchargements par semaine. Ne construis rien dessus.
• Les scrapers auto-hébergés comme ovnrain/javbus-api te donnent un conteneur Docker qui scrape à ta place. Plus agréable à faire tourner, même fondation, casse toujours quand le site source change son balisage.
• Les outils de serveur multimédia (Javinizer, le plugin JavScraper pour Emby/Jellyfin) sont parfaits pour organiser une bibliothèque locale, mais n’ont jamais été conçus comme une API de données que tu appelles depuis ta propre app.

Pourquoi ils finissent tous par casser

Ces outils scrapent un site web en direct, donc ils héritent de chaque défense que ce site possède. JavDB se trouve derrière Cloudflare, et la moitié de ces projets ont besoin de FlareSolverr en parallèle juste pour récupérer une page. Certains contenus (fc2) nécessitent un cookie de session que tu colles à la main et que tu rafraîchis quand il expire. Un renommage de classe sur le site casse discrètement ton parser, sans changelog ni avertissement, et tes métadonnées deviennent simplement vides un jour. Et comme les métadonnées de JavDB sont en anglais et chinois uniquement, tout ce qui repose dessus manque les champs japonais.

Tu ne maintiens donc pas une intégration. Tu maintiens un scraper, un contournement par navigateur headless, un cookie et un bipeur pour quand tout s’écroule à 2h du matin.

Une alternative hébergée

javinfo est l’API que JavDB ne t’a jamais donnée. Elle a un véritable fournisseur javdb : envoie un code, reçois des métadonnées structurées en retour, y compris les liens de téléchargement et magnet que les scrapers cherchent à obtenir. La même forme à chaque fois, rien à surveiller.

curl -X POST "https://api.javinfo.dev/movie" \
  -H "x-javinfo-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "q": "CAWD-001", "providers": "javdb" }'

{
  "q": "CAWD-001",
  "source": "javdb",
  "result": {
    "dvdId": "CAWD-001",
    "runtimeMins": 120,
    "extra": {
      "downloadLinks": [
        { "name": "CAWD-001 1080p", "magnet": "magnet:?xt=urn:btih:...", "size": 5905580032, "hd": true }
      ],
      "score": 4.3,
      "voteCount": 512
    }
  }
}

Chaque fournisseur se mappe sur la même forme de base result, donc tu lis result.* de la même manière, peu importe la source qui a répondu. On gère le scraping et les combats contre Cloudflare pour que tu n’aies pas à le faire. C’est une pièce d’une unique API de métadonnées JAV couvrant chaque source, indépendante des fournisseurs par conception — une seule intégration maintenue au lieu d’un tas de scrapers fragiles. JavDB est loin d’être la seule source de ce genre. DMM est pire.

Inscris-toi sur app.javinfo.dev, récupère une clé et passe-la dans l’en-tête x-javinfo-key (également disponible sur RapidAPI). Le fournisseur javdb et ses liens de téléchargement reviennent à chaque requête — pas de paliers, pas de gating — aux côtés du fournisseur missav. La facturation se fait à l’usage : /movie coûte 0,001 $ par résultat réussi et /query coûte 0,0002 $, et tu démarres avec 1 000+ recherches offertes, sans carte bancaire (ensuite tu recharges en USDC, crédité 1:1). Tu peux être opérationnel en une minute. Pas de Docker, pas de FlareSolverr, pas de cookie.