EN
Copied
API

API Registre des modules

Source de vérité unique listant tous les modules exposés par la plateforme — scrapers actifs, stubs on-demand, méta-fonctionnalités, items à venir.

API Registre des modules

Le Registre de modules est la source de vérité unique qui liste tous les modules exposés par la plateforme : scrapers actifs, stubs on-demand, méta-fonctionnalités et items à venir qui collectent encore des votes d'intérêt. Le frontend lit le registre au lieu de coder en dur les slugs de modules, donc ajouter un module ne demande que deux fichiers (frontend/static/job_types.js et app/job_registry.py).

Voir aussi : /docs/fr/concepts/module-registry.

Forme d'une entrée

Chaque module est décrit par un petit objet que le frontend rend dans les tuiles du tableau de bord, la palette de recherche et les pages tarif.

Champ Type Rôle
slug string Identifiant stable. Utilisé comme job_type, paramètre de route et clé.
category string Bucket de groupe (sources, enrich, signals, outreach, tools).
label objet { "fr": "...", "en": "..." }. Nom d'affichage bilingue.
needs string[] Artefacts amont consommés (ex. ["leads"]).
produces string[] Artefacts aval émis (ex. ["emails"]).
pipelinable boolean Le module peut-il être chaîné dans un Pipeline.
is_on_demand boolean Module stub — cliquer activer ouvre un fil de feedback, pas un job.
coming_soon boolean Listé pour le vote d'intérêt seulement. Pas d'exécution backend.
alpha_unavailable boolean Construit et listé comme actif, mais gelé pendant l'alpha. Son endpoint de création renvoie 503.
api_endpoint string | null Chemin appelé par le tableau de bord pour lancer un run, ou null.

Un module est au plus l'un de is_on_demand, coming_soon, alpha_unavailable, ou actif. Les modules actifs ont un api_endpoint non-null ; les stubs et coming-soon ont api_endpoint = null. Un module alpha_unavailable se présente comme actif et garde un api_endpoint non-null, mais cet endpoint renvoie 503 tant que le gel alpha est en vigueur.

GET /api/modules-registry

Endpoint public. Renvoie le miroir côté serveur du registre JS. La réponse est un objet plat avec un tableau par bucket plus un mapping feature_pages qui pointe chaque module actif vers sa page de vente publiée /features/<slug> (ou null si pas encore écrite).

Réponse — 200 OK

{
  "active": [
    "ads_intelligence", "brand_assets", "dead_check", "delivery_check",
    "emails", "filter", "import", "legal_data", "legal_ids",
    "legal_mentions", "pagespeed", "phones_extra", "pricing", "reviews",
    "scrap", "socials", "sort", "techstack", "verify_emails",
    "viewport_test"
  ],
  "multi_proxy": [
    "dead_check", "emails", "legal_ids", "legal_mentions", "phones_extra",
    "pricing", "reviews", "scrap", "socials", "techstack"
  ],
  "parallel": [
    "ads_intelligence", "brand_assets", "delivery_check", "filter",
    "import", "legal_data", "pagespeed", "sort", "verify_emails",
    "viewport_test"
  ],
  "on_demand": [
    "email_campaign", "phone_carrier", "sms_campaign", "whatsapp_campaign"
  ],
  "meta": ["pipeline", "veille"],
  "coming_soon": [
    "ai_personalization", "ai_team_members", "bing_places", "campaign",
    "chrome_extension", "crm", "directories", "email_warmup",
    "funding", "hiring", "integrations", "job_changes", "linkedin",
    "mobile_phones", "multichannel", "natural_filter", "pagesjaunes",
    "press_monitoring", "public_api", "review_patterns", "seo_data",
    "tech_adoption", "tracking", "whatsapp", "yelp_tripadvisor"
  ],
  "alpha_unavailable": ["finance"],
  "feature_pages": {
    "scrap": "scraper-google-maps-gratuit-export-csv",
    "emails": "email-finder-pro-rgpd-france",
    "ads_intelligence": null
  }
}

L'ensemble multi_proxy liste les scrapers qui partagent le pool VPN global — un seul peut tourner à la fois à l'échelle plateforme. Les modules parallel utilisent HTTP direct et peuvent tourner en concurrence. Les clients qui planifient des jobs devraient vérifier les deux ensembles pour faire ressortir des avertissements "Sera en file".

GET /api/features

Renvoie l'état d'intérêt de l'appelant plus un compteur global par fonctionnalité coming-soon. Les comptes incluent chaque id de fonctionnalité autorisée, même ceux à zéro vote, afin que le frontend puisse rendre les libellés Souhaité (N) sans branche de fallback.

La liste des ids acceptables égale coming_soon du registre, plus un petit ensemble legacy (company, monitoring, pagespeed) conservé pour préserver les votes historiques.

Réponse — 200 OK

{
  "voted": ["linkedin", "funding"],
  "counts": {
    "linkedin": 27,
    "funding": 14,
    "hiring": 6,
    "ai_personalization": 3,
    "directories": 0,
    "press_monitoring": 0
  }
}

Cause spécifique : 401 appelant non authentifié.

POST /api/features/{feature_id}/interest

Enregistre un vote d'intérêt pour feature_id. L'opération est idempotente — un second appel par le même utilisateur est un no-op. Utiliser DELETE sur le même chemin pour retirer le vote.

feature_id est validé contre l'allow-list du registre (ids coming-soon plus ids legacy). Les ids inconnus renvoient 404 afin que l'endpoint ne puisse pas servir de KV store écrit-partout.

Requête

POST /api/features/linkedin/interest

Pas de corps. L'utilisateur est identifié par session.

Réponse — 204 No Content

Corps vide. Re-récupérer GET /api/features pour le compteur mis à jour.

Causes spécifiques : 401 non authentifié ; 403 authentifié mais pas actif (invitation en attente) ; 404 feature_id hors allow-list du registre.

Liens