Workflow n8n de génération de leads (pas à pas)

Si vous construisez un workflow n8n de génération de leads pour la prospection locale, le point difficile est d'obtenir des fiches d'entreprises fiables, des sites web, des numéros de téléphone et des e-mails de contact sans maintenir de sélecteurs de navigateur ni de scripts de scraping fragiles. biz collect offre à n8n une voie plus propre : envoyez une requête HTTP avec une localisation, des mots-clés, un rayon et une option d'extraction d'e-mails, recevez un job_id asynchrone, puis interrogez jusqu'à ce que les résultats JSON structurés soient prêts. Ce guide montre comment construire un workflow n8n Google Maps complet qui trouve des entreprises locales, extrait des e-mails dédupliqués depuis leurs sites web et envoie les résultats vers Google Sheets, HubSpot, Slack ou tout système en aval.

Pourquoi utiliser une API pour la génération de leads locaux dans n8n ?

n8n excelle à connecter des systèmes : déclencheurs, appels HTTP, branches conditionnelles, transformations de données, tableurs, CRM, alertes et jobs planifiés. Mais la génération de leads locaux comporte une étape d'acquisition de données qui devient vite désordonnée si vous tentez de l'automatiser par du scraping de navigateur seul.

Un montage typique "n8n Google Maps leads" commence souvent par un navigateur headless, une URL de recherche, des sélecteurs pour les cartes de résultats et une logique de scraping distincte pour les sites web et les e-mails. Cela peut fonctionner pour de petites expériences, mais cela crée du travail de maintenance. Les mises en page changent, les sessions de navigateur échouent, les sélecteurs cassent, et l'extraction d'e-mails devient un second scraper. Si vous en êtes là aujourd'hui, le guide sur l'alternative à un scraper Google Maps qui renvoie du JSON montre la voie API-first sur laquelle repose ce workflow.

biz collect est conçu pour la forme opposée. C'est une API de contacts d'entreprises native pour les LLM, construite pour les agents, les outils de workflow, les scripts et l'enrichissement CRM. Vous appelez /api/v1/search avec des paramètres comme location, keywords, radius_km et scrape_emails. L'API renvoie un job en file d'attente. Vous interrogez /api/v1/jobs/:id jusqu'à ce qu'il se termine, puis utilisez les fiches JSON renvoyées dans le reste de votre workflow n8n. Si vous choisissez encore une source, cette comparaison de comment se comparent la Places API, un scraper Google Maps et une API vous aide à décider.

Cela signifie que votre workflow n8n peut se concentrer sur le routage des leads :

• Lancer des recherches sur planning ou depuis une soumission de formulaire.
• Demander des données d'entreprises locales structurées à biz collect.
• Attendre et interroger jusqu'à la fin du job asynchrone.
• Diviser les entreprises renvoyées en items individuels.
• Filtrer, enrichir, dédupliquer ou scorer les fiches.
• Envoyer les leads qualifiés vers Google Sheets, HubSpot, Slack, Airtable, Notion ou une autre destination.

Pour les détails d'API, commencez par les docs API de biz collect, les exemples d'intégration dans Intégrations et les infos de plan dans Tarifs. Pour voir le modèle recherche-et-polling asynchrone avant de construire, la page comment fonctionne biz collect parcourt le même cycle de requête que ce workflow automatise. La documentation de n8n est utile pour les nodes standard employés ici, notamment le node HTTP Request, le node Wait, le node IF et le node Google Sheets.

Ce que construit ce workflow

Le workflow de ce tutoriel automatise les leads locaux de la requête de recherche jusqu'à la sortie vers la destination. Il utilise le comportement standard de n8n et des nodes HTTP, biz collect gérant la recherche d'entreprises et n8n l'orchestration.

Le workflow final ressemble à ceci :

1. Un déclencheur lance le workflow manuellement, sur planning ou depuis un webhook.
2. Un node HTTP Request envoie une requête POST vers /api/v1/search de biz collect.
3. La réponse renvoie un job_id et le statut du job.
4. Un node Wait fait une brève pause avant le polling.
5. Un second node HTTP Request appelle /api/v1/jobs/:id.
6. Un node IF vérifie si le statut du job est completed.
7. S'il n'est pas terminé, le workflow attend et interroge à nouveau, avec une limite de tentatives.
8. Une fois terminé, un node Code ou de découpage d'items transforme les entreprises renvoyées en items n8n individuels.
9. Des nodes de destination envoient les leads vers Google Sheets, HubSpot, Slack ou un autre système.
10. Des branches d'erreur gèrent les jobs échoués, les timeouts et les jeux de résultats vides.

Vous pouvez adapter le même schéma pour de la prospection ponctuelle, des scans de marché récurrents, des listes de leads d'agence, l'enrichissement CRM, la recherche SEO locale, la découverte de partenaires ou des workflows d'agent IA qui ont besoin de données de contact d'entreprises locales vérifiées.

Prérequis

Avant de construire le workflow, il vous faut :

• Une instance n8n, n8n Cloud ou auto-hébergée.
• Une clé API biz collect.
• Une destination pour les leads, comme Google Sheets, HubSpot ou Slack.
• Une définition de recherche claire : localisation, mots-clés de catégorie, rayon et si vous voulez extraire les e-mails des sites web.

biz collect est actuellement gratuit au départ avec 200 crédits d'inscription et sans carte bancaire. C'est suffisant pour construire, tester et lancer de petits jobs de prospection avant de mettre l'automatisation sur un planning de production. Consultez Tarifs pour les limites de plan actuelles.

Flux de données et forme de l'API

biz collect utilise un flux de job asynchrone car la recherche d'entreprises locales et l'extraction d'e-mails de sites web peuvent prendre plus de temps qu'une requête HTTP synchrone normale. n8n gère cela bien car les workflows peuvent attendre, se ramifier et interroger.

La requête de base est un POST vers :

https://bizcollect.dev/api/v1/search

Le corps contient les entrées de recherche locale :

{
  "location": "Austin, TX",
  "keywords": ["dentist", "orthodontist"],
  "radius_km": 15,
  "scrape_emails": true
}

La réponse contient un identifiant de job. La réponse exacte peut inclure d'autres champs, mais le workflow n'a besoin que du job_id et du statut :

{
  "job_id": "job_123456",
  "status": "queued",
  "poll_url": "/api/v1/jobs/job_123456"
}

Puis n8n interroge :

GET https://bizcollect.dev/api/v1/jobs/job_123456

Une fois terminé, le résultat contient des fiches d'entreprises structurées. Une réponse terminée représentative ressemble à ceci :

{
  "job_id": "job_123456",
  "status": "completed",
  "businesses": [
    {
      "name": "Example Dental Studio",
      "address": "123 Main St, Austin, TX 78701",
      "phone": "+1 512-555-0101",
      "website": "https://exampledentalstudio.com",
      "emails": ["hello@exampledentalstudio.com", "office@exampledentalstudio.com"]
    }
  ]
}

Le contrat du workflow est stable : lancer une recherche, recevoir un job_id, interroger le endpoint du job, puis traiter des fiches JSON structurées. Pour le schéma faisant autorité, utilisez la référence OpenAPI dans les docs biz collect.

Étape 1 : Créer le déclencheur

Commencez par le déclencheur qui correspond à votre cas d'usage. Les trois choix courants sont :

• Manual Trigger pour les tests et les recherches ponctuelles.
• Schedule Trigger pour la prospection récurrente, par exemple chaque lundi matin.
• Webhook Trigger lorsqu'un autre système ou agent doit lancer une recherche dynamiquement.

Pour une première version, utilisez un Manual Trigger et codez en dur une localisation et des mots-clés dans le premier node HTTP. Une fois le workflow stable, remplacez les valeurs fixes par des données d'un Schedule Trigger, d'une soumission de formulaire, d'un segment CRM ou d'un payload de webhook.

Si vous voulez que le workflow accepte des recherches dynamiques d'un autre outil, utilisez un Webhook Trigger et envoyez un corps comme :

{
  "location": "Zurich, Switzerland",
  "keywords": ["law firm", "tax advisor"],
  "radius_km": 10,
  "scrape_emails": true
}

Le corps de la requête biz collect peut alors référencer les champs entrants du webhook avec des expressions n8n. Gardez votre premier workflow simple, confirmez la forme de la réponse de l'API, puis paramétrez.

Étape 2 : Ajouter le node HTTP Request pour /api/v1/search

Ajoutez un node HTTP Request après le déclencheur. Nommez-le Start biz collect Search.

Configurez le node :

• Method : POST
• URL : https://bizcollect.dev/api/v1/search
• Authentication : un en-tête de clé API ou votre configuration de credential n8n préférée
• Response format : JSON
• Send body : JSON

Utilisez cet en-tête d'autorisation :

Authorization: Bearer YOUR_BIZCOLLECT_API_KEY
Content-Type: application/json

Pour une recherche de test fixe, utilisez ce corps JSON :

{
  "location": "Miami, FL",
  "keywords": ["med spa", "aesthetic clinic"],
  "radius_km": 20,
  "scrape_emails": true
}

Pour une version Webhook Trigger, utilisez des expressions :

{
  "location": "={{ $json.location }}",
  "keywords": "={{ $json.keywords }}",
  "radius_km": "={{ $json.radius_km || 15 }}",
  "scrape_emails": "={{ $json.scrape_emails ?? true }}"
}

Si votre déclencheur passe keywords sous forme de chaîne séparée par des virgules au lieu d'un tableau, normalisez-la avant la requête HTTP avec un node Set ou Code. biz collect attend une entrée de mots-clés claire ; un tableau est généralement le plus simple à contrôler en automatisation.

Exemple de normalisation avec un node Code :

const keywords = Array.isArray($json.keywords)
  ? $json.keywords
  : String($json.keywords || "")
      .split(",")
      .map((keyword) => keyword.trim())
      .filter(Boolean);

return [
  {
    json: {
      location: $json.location,
      keywords,
      radius_km: Number($json.radius_km || 15),
      scrape_emails: $json.scrape_emails !== false
    }
  }
];

Puis référencez les champs normalisés dans le corps HTTP :

{
  "location": "={{ $json.location }}",
  "keywords": "={{ $json.keywords }}",
  "radius_km": "={{ $json.radius_km }}",
  "scrape_emails": "={{ $json.scrape_emails }}"
}

Après l'exécution de ce node, vous devriez avoir un item avec job_id, status et éventuellement poll_url. Si la requête échoue, vérifiez la clé API, le corps de la requête et les limites actuelles dans Tarifs.

Étape 3 : Stocker le Job ID pour le polling

Avant de poller, assurez-vous que le job_id est disponible pour les nodes suivants. Dans de nombreux workflows n8n, le node suivant peut référencer directement :

{{ $json.job_id }}

Si vous préférez rendre le workflow plus explicite, ajoutez un node Set nommé Keep Job ID avec les champs :

{
  "job_id": "={{ $json.job_id }}",
  "poll_url": "={{ $json.poll_url }}",
  "poll_attempt": 0
}

Cela donne à la boucle de polling une forme d'item propre. Un compteur de tentatives est utile car tout workflow asynchrone devrait avoir une condition d'arrêt claire. Même quand l'API est saine, des pannes réseau, de mauvaises entrées ou des limites en aval peuvent survenir. Un workflow qui ne peut que boucler indéfiniment est difficile à exploiter.

Étape 4 : Attendre avant le premier poll

Ajoutez un node Wait après la requête de recherche. Nommez-le Wait Before Polling.

Pour la plupart des workflows, commencez par un court délai de 10 à 30 secondes. L'extraction d'e-mails exige que l'API visite les sites web des entreprises, analyse les pages et déduplique les adresses candidates, donc poller immédiatement après la requête de recherche ajoute généralement du bruit sans améliorer le résultat.

Un point de départ pratique :

• Wait amount : 15
• Unit : seconds

Pour les recherches à grand rayon ou à larges jeux de mots-clés, augmentez le délai. Pour les petits jobs d'enrichissement, réduisez-le. Vous pouvez l'ajuster après avoir observé les durées réelles des jobs dans votre compte.

Étape 5 : Poller /api/v1/jobs/:id

Ajoutez un autre node HTTP Request nommé Poll biz collect Job.

Configurez-le :

• Method : GET
• URL : =https://bizcollect.dev/api/v1/jobs/{{ $json.job_id }}
• Authentication : le même en-tête de clé API que la requête de recherche
• Response format : JSON

En-tête :

Authorization: Bearer YOUR_BIZCOLLECT_API_KEY

La réponse de polling devrait inclure le statut actuel du job. Votre workflow devrait se ramifier sur ce statut plutôt que de supposer que le premier poll est terminé.

Statuts typiques à gérer :

• queued ou running : attendre et poller à nouveau.
• completed : traiter businesses.
• failed : arrêter le workflow et alerter quelqu'un ou logguer l'échec.

Utilisez les champs de statut réels des docs API comme source de vérité. La logique du workflow reste la même même si vous ajoutez plus tard une gestion spécifique par statut.

Étape 6 : Ajouter un node IF pour les jobs terminés

Ajoutez un node IF nommé Is Job Completed?.

La condition principale devrait vérifier :

{{ $json.status }} equals completed

La branche true continue vers le traitement des résultats. La branche false a besoin de plus de logique car un job peut encore tourner ou avoir échoué.

Pour un premier workflow, ajoutez un second node IF sur la branche false, nommé Did Job Fail? :

{{ $json.status }} equals failed

Si failed est vrai, envoyez une alerte Slack, écrivez une ligne d'erreur ou arrêtez l'exécution. Si failed est faux, supposez que le job est encore en attente ou en cours et continuez vers un compteur de tentatives.

Cela crée une branche claire :

• Terminé : découper et sortir les leads.
• Échoué : signaler l'échec.
• Toujours en cours : attendre et poller à nouveau.

Étape 7 : Ajouter la logique de tentatives et de timeout

Un workflow n8n de production d'extraction d'e-mails d'entreprises ne devrait pas poller indéfiniment. Ajoutez un compteur de tentatives avant que la boucle ne revienne au node Wait.

Une méthode simple consiste à insérer un node Code nommé Increment Poll Attempt sur la branche encore-en-cours :

const attempt = Number($json.poll_attempt || 0) + 1;

return [
  {
    json: {
      ...$json,
      poll_attempt: attempt,
      max_poll_attempts: Number($json.max_poll_attempts || 20)
    }
  }
];

Puis ajoutez un node IF nommé Can Poll Again? :

{{ $json.poll_attempt }} is smaller than {{ $json.max_poll_attempts }}

S'il est vrai, reconnectez au node Wait et pollez à nouveau. S'il est faux, envoyez une alerte de timeout ou écrivez le job vers une destination d'erreur pour suivi.

Avec un node Wait de 15 secondes et 20 tentatives maximum, le workflow attend environ cinq minutes avant le timeout. Vous pouvez ajuster ces chiffres selon votre cas d'usage :

• Tests de prospection rapides : 10 tentatives à 10 secondes.
• Jobs d'extraction d'e-mails : 20 tentatives à 15 secondes.
• Grandes recherches récurrentes : 30 tentatives à 30 secondes.

La bonne valeur est opérationnelle, pas théorique. Fixez une limite qui laisse aux jobs normaux le temps de finir tout en faisant remonter les retards inattendus.

Étape 8 : Diviser les entreprises en items individuels

Une fois status à completed, la réponse contient un tableau d'entreprises. La plupart des nodes de destination fonctionnent mieux quand chaque entreprise est son propre item n8n.

Ajoutez un node Code nommé Split Businesses.

Utilisez ce code :

const businesses = $json.businesses || [];

return businesses.map((business) => ({
  json: {
    job_id: $json.job_id,
    name: business.name || "",
    address: business.address || "",
    phone: business.phone || "",
    website: business.website || "",
    emails: business.emails || [],
    primary_email: Array.isArray(business.emails) && business.emails.length > 0
      ? business.emails[0]
      : "",
    email_count: Array.isArray(business.emails) ? business.emails.length : 0
  }
}));

Cela donne à chaque node en aval une forme d'item prévisible :

{
  "job_id": "job_123456",
  "name": "Example Dental Studio",
  "address": "123 Main St, Austin, TX 78701",
  "phone": "+1 512-555-0101",
  "website": "https://exampledentalstudio.com",
  "emails": ["hello@exampledentalstudio.com"],
  "primary_email": "hello@exampledentalstudio.com",
  "email_count": 1
}

Si le workflow est spécifiquement pour la vente sortante, ajoutez un filtre après le découpage :

{{ $json.primary_email }} is not empty

Cela garde le CRM ou le tableur concentré sur les leads ayant des données de contact directes. Si votre équipe commerciale appelle aussi les prospects, gardez les fiches avec numéros de téléphone même quand aucun e-mail n'est trouvé.

Étape 9 : Envoyer les leads vers Google Sheets

Google Sheets est la destination la plus facile pour commencer car elle rend la sortie visible et facile à inspecter. Ajoutez un node Google Sheets après Split Businesses.

Colonnes recommandées :

• Search Job ID
• Business Name
• Address
• Phone
• Website
• Primary Email
• All Emails
• Email Count
• Created At

Mappez les champs ainsi :

{
  "Search Job ID": "={{ $json.job_id }}",
  "Business Name": "={{ $json.name }}",
  "Address": "={{ $json.address }}",
  "Phone": "={{ $json.phone }}",
  "Website": "={{ $json.website }}",
  "Primary Email": "={{ $json.primary_email }}",
  "All Emails": "={{ $json.emails.join(', ') }}",
  "Email Count": "={{ $json.email_count }}",
  "Created At": "={{ new Date().toISOString() }}"
}

Pour une stratégie de déduplication légère, utilisez le site web ou l'e-mail principal comme valeur unique. Si votre configuration Google Sheets ne fait qu'ajouter des lignes, ajoutez une étape de nettoyage ultérieure ou utilisez une destination base de données pour une unicité plus stricte. Pour les workflows CRM, la déduplication devrait normalement se produire avant de créer de nouvelles fiches d'entreprise ou de contact.

Étape 10 : Envoyer les leads qualifiés vers HubSpot

Pour HubSpot, le flux le plus courant est :

1. Rechercher une entreprise existante par domaine ou site web.
2. Si aucune correspondance n'existe, créer une entreprise.
3. Si primary_email existe, rechercher un contact existant par e-mail.
4. Si aucun contact n'existe, créer un contact.
5. Associer le contact à l'entreprise si votre configuration HubSpot l'exige.

La configuration exacte du node HubSpot dépend de votre compte, de vos propriétés et de votre modèle d'objets, gardez donc la première version conservatrice. Ne créez pas de contacts en double juste parce qu'une entreprise a plusieurs e-mails. Commencez par primary_email, puis stockez optionnellement la liste complète d'e-mails dédupliqués dans une propriété personnalisée ou une note.

Mapping d'entreprise utile :

{
  "name": "={{ $json.name }}",
  "domain": "={{ $json.website.replace(/^https?:\\/\\//, '').replace(/^www\\./, '').split('/')[0] }}",
  "phone": "={{ $json.phone }}",
  "address": "={{ $json.address }}",
  "website": "={{ $json.website }}"
}

Mapping de contact utile :

{
  "email": "={{ $json.primary_email }}",
  "company": "={{ $json.name }}",
  "phone": "={{ $json.phone }}",
  "website": "={{ $json.website }}"
}

Si votre CRM a des règles de données strictes, ajoutez une validation avant HubSpot :

• Ne créer des contacts que lorsque primary_email n'est pas vide.
• Ne créer des entreprises que lorsque website ou phone est présent.
• Ajouter un champ de source tel que biz collect n8n workflow.
• Ajouter la localisation de recherche et le jeu de mots-clés comme contexte de campagne.

Cela facilite le reporting sur quelles recherches locales ont généré des leads utiles.

Étape 11 : Envoyer un résumé Slack

Slack est utile pour la visibilité opérationnelle. Au lieu de poster chaque lead individuellement, postez un résumé compact quand un job se termine.

Ajoutez un node Code avant le node Slack si vous devez résumer le job terminé avant le découpage :

const businesses = $json.businesses || [];
const withEmail = businesses.filter((business) =>
  Array.isArray(business.emails) && business.emails.length > 0
);

return [
  {
    json: {
      job_id: $json.job_id,
      status: $json.status,
      business_count: businesses.length,
      businesses_with_email: withEmail.length,
      sample_names: businesses.slice(0, 5).map((business) => business.name).join(", ")
    }
  }
];

Puis envoyez un message Slack :

biz collect job {{ $json.job_id }} completed.
Businesses found: {{ $json.business_count }}
With email: {{ $json.businesses_with_email }}
Sample: {{ $json.sample_names }}

Pour les branches d'erreur, envoyez un message différent :

biz collect job {{ $json.job_id }} did not complete.
Status: {{ $json.status }}
Poll attempts: {{ $json.poll_attempt }}

Cela vous donne assez de contexte pour surveiller les workflows récurrents sans ouvrir n8n à chaque exécution.

Disposition de workflow recommandée

Voici la séquence complète de nodes pour une version pratique :

Manual Trigger
  -> Start biz collect Search
  -> Keep Job ID
  -> Wait Before Polling
  -> Poll biz collect Job
  -> Is Job Completed?
      true:
        -> Split Businesses
        -> Has Email?
        -> Google Sheets / HubSpot / Slack
      false:
        -> Did Job Fail?
            true:
              -> Slack Error Alert
            false:
              -> Increment Poll Attempt
              -> Can Poll Again?
                  true:
                    -> Wait Before Polling
                  false:
                    -> Slack Timeout Alert

Ce schéma est volontairement simple. Il évite l'infrastructure sur mesure tout en gérant les réalités des API asynchrones : le travail peut être mis en file, les jobs peuvent tourner un moment, et les jobs échoués ou longs ont besoin d'un chemin adapté aux opérateurs.

Liste de contrôle de gestion des erreurs

Ne remettez pas la gestion des erreurs à plus tard. Un workflow de génération de leads tourne généralement sur planning, ce qui signifie que les échecs silencieux créent des pipelines périmés.

Ajoutez une gestion pour ces cas :

• Requête non autorisée : clé API manquante ou invalide. Arrêter immédiatement et notifier le propriétaire du workflow.
• Requête invalide : location manquant, keywords vide ou radius_km invalide. Écrire l'entrée échouée dans une feuille d'erreurs.
• Limite de débit ou de plan : mettre le workflow en pause et envoyer une alerte avec un lien vers Tarifs.
• Job échoué : notifier Slack et inclure le job_id.
• Timeout du job : inclure poll_attempt et le dernier statut connu.
• Aucune entreprise renvoyée : écrire un résultat réussi mais vide avec les paramètres de recherche.
• Entreprises sans e-mails : les garder si l'appel téléphonique ou la revue du site compte ; les filtrer si l'e-mail est requis.

Pour les workflows planifiés, ajoutez une destination de journal d'exécution. Une simple Google Sheet fonctionne :

{
  "timestamp": "={{ new Date().toISOString() }}",
  "location": "={{ $json.location }}",
  "keywords": "={{ Array.isArray($json.keywords) ? $json.keywords.join(', ') : $json.keywords }}",
  "job_id": "={{ $json.job_id }}",
  "status": "={{ $json.status }}",
  "poll_attempt": "={{ $json.poll_attempt || 0 }}"
}

Cela facilite le débogage quand un interlocuteur demande pourquoi un territoire précis n'a pas produit de nouveaux leads.

Règles de déduplication et de qualité des leads

biz collect déduplique les e-mails de contact extraits des sites web d'entreprises, mais vous devriez tout de même dédupliquer au niveau de votre destination. La même entreprise peut apparaître dans plusieurs recherches, surtout quand les jeux de mots-clés se chevauchent.

Bonnes clés de déduplication :

• Domaine du site web
• E-mail principal
• Numéro de téléphone
• Combinaison du nom de l'entreprise et de l'adresse

Pour Google Sheets, une simple formule ou un lookup peut signaler les doublons. Pour HubSpot et d'autres CRM, utilisez les étapes natives rechercher-avant-créer. Pour les bases de données, imposez l'unicité sur un domaine de site web normalisé ou un e-mail principal quand c'est possible.

Vous pouvez aussi ajouter un scoring de qualité des leads dans n8n :

let score = 0;

if ($json.website) score += 20;
if ($json.phone) score += 15;
if ($json.primary_email) score += 40;
if ($json.email_count > 1) score += 10;
if ($json.address) score += 15;

return [
  {
    json: {
      ...$json,
      lead_score: score,
      qualified: score >= 60
    }
  }
];

Puis ramifiez :

{{ $json.qualified }} is true

Les leads qualifiés vont vers HubSpot. Les leads moins bien notés vont vers une feuille de revue. Cela garde votre CRM plus propre tout en préservant des données de marché utiles.

Commencer à construire

Le workflow n8n de génération de leads le plus simple mais utile ne compte que quelques nodes : déclencheur, requête HTTP, wait, poll, IF, split et sortie. La valeur vient d'utiliser une API qui renvoie des données d'entreprises structurées et des e-mails de sites web vérifiés plutôt que de demander à n8n de maintenir un scraper.

biz collect est construit pour exactement ce schéma : une requête POST pour lancer une recherche d'entreprises locales, un polling asynchrone jusqu'à la fin, des champs JSON stables, des docs OpenAPI 3.1 et des e-mails de contact dédupliqués extraits des sites web d'entreprises. Il s'adapte à n8n, Make, Zapier, aux scripts, aux outils LLM et aux workflows d'enrichissement CRM sans maintenance de navigateur headless. Si vous pesez encore les options, le guide des meilleurs outils de génération de leads locaux en 2026 montre où un workflow n8n-plus-API se place parmi les scrapers, outils no-code et CRM.

Vous pouvez commencer gratuitement avec 200 crédits d'inscription et sans carte bancaire. Ouvrez les docs API, consultez les intégrations, vérifiez les tarifs et construisez aujourd'hui votre premier workflow de leads locaux automatisés dans n8n.