Si estás construyendo un workflow Make.com de generación de leads para la prospección local, el paso de adquisición de datos es donde la mayoría de los escenarios se complican. Encontrar negocios locales, sus sitios web, números de teléfono y emails de contacto suele significar mantener scrapers de navegador y selectores que se rompen. biz collect le ofrece a Make una vía más limpia: un módulo HTTP envía una localización y palabras clave a /v1/search, recibes un job_id asíncrono, y luego un ciclo de polling comprueba /v1/jobs/:id hasta que el JSON estructurado está listo. Esta guía construye un escenario Make completo que encuentra negocios locales, extrae emails deduplicados de sus sitios web y escribe los resultados en Google Sheets, un CRM o cualquier app posterior.
¿Por qué usar una API para la generación de leads en Make?
Make (antes Integromat) es excelente conectando apps: triggers, llamadas HTTP, routers, iterators, aggregators, data stores y escenarios programados. Pero la generación de leads local tiene un paso de adquisición de datos que se vuelve frágil si intentas automatizarlo con scraping de navegador dentro de Make.
Un montaje típico de "Make Google Maps scraper" parte de un servicio de navegador headless, una URL de búsqueda, selectores para las tarjetas de resultados y una lógica separada para visitar cada sitio web y encontrar los emails. Puede funcionar para una demo, pero genera mantenimiento continuo. Los diseños cambian, las sesiones fallan, los selectores se rompen y la extracción de emails se convierte en un segundo scraper que vigilar. Si estás sopesando esto frente a una API de datos, el compromiso entre la Google Places API, los scrapers y las API de datos de empresas expone las diferencias.
biz collect está diseñado para la forma opuesta. Es una API de contactos de empresas nativa para LLM, construida para agentes, herramientas de workflow, scripts y enriquecimiento CRM. Llamas a /api/v1/search con parámetros como location, keywords, radius_km y scrape_emails. La API devuelve un job en cola. Haces polling en /api/v1/jobs/:id hasta que se completa, y luego usas los registros JSON devueltos en el resto de tu escenario.
Esto deja que tu escenario Make se centre en el enrutamiento:
- Ejecutar búsquedas de forma programada o desde un webhook.
- Solicitar datos de negocios locales estructurados a biz collect.
- Esperar y hacer polling hasta que el job asíncrono se complete.
- Dividir los negocios devueltos en bundles individuales.
- Filtrar, deduplicar o puntuar los registros.
- Enviar los leads cualificados a Google Sheets, HubSpot, Pipedrive, Airtable, Notion u otra app.
Para los detalles de la API, empieza por los docs de la API, los ejemplos de integración en integraciones y los límites de plan en precios. Si quieres ver el modelo de búsqueda-y-polling asíncrono antes de construir, la página cómo funciona biz collect recorre el mismo ciclo que este escenario automatiza. La documentación de Make es útil para los módulos estándar usados aquí, en particular el módulo HTTP, la herramienta Sleep, el Iterator y el módulo Google Sheets.
Qué construye este escenario
El escenario de este tutorial automatiza los leads locales desde la petición de búsqueda hasta la salida hacia el destino. Usa módulos Make estándar, con biz collect encargándose de la búsqueda de negocios y Make de la orquestación.
El escenario final tiene este aspecto:
- Un trigger inicia el escenario manualmente, de forma programada o desde un webhook.
- Un módulo HTTP envía una petición
POSTa/api/v1/searchde biz collect. - La respuesta devuelve un
job_idy el estado del job. - Un módulo Sleep pausa brevemente antes del polling.
- Un segundo módulo HTTP llama a
/api/v1/jobs/:id. - Un router o repeater verifica si el estado del job es
completed. - Si no está completo, el escenario espera y hace polling de nuevo, con un límite de intentos.
- Una vez completo, un Iterator transforma los negocios devueltos en bundles individuales.
- Los módulos de destino envían los leads a Google Sheets, un CRM u otra app.
- Las rutas de error gestionan jobs fallidos, timeouts y conjuntos de resultados vacíos.
Puedes adaptar el mismo patrón para prospección puntual, escaneos de mercado recurrentes, listas de leads para agencias, enriquecimiento CRM o workflows de agentes IA que necesitan datos de contacto de negocios locales verificados.
Requisitos previos
Antes de construir el escenario, necesitas:
- Una cuenta de Make, en cualquier plan que permita los módulos HTTP.
- Una clave API de biz collect.
- Un destino para los leads, como Google Sheets, HubSpot o Pipedrive.
- Una definición de búsqueda clara: localización, palabras clave de categoría, radio y si extraer emails de los sitios web.
biz collect es gratuito para empezar con 200 créditos de registro y sin tarjeta de crédito. Es suficiente para construir, probar y ejecutar pequeños jobs de prospección antes de poner el escenario en una programación de producción. Consulta precios para los límites de plan actuales.
Flujo de datos y forma de la API
biz collect usa un flujo de job asíncrono porque la búsqueda de negocios locales y la extracción de emails de los sitios web pueden tardar más que una petición HTTP síncrona normal. Make gestiona esto bien porque los escenarios pueden dormir, ramificarse y repetirse.
La petición base es un POST a:
https://bizcollect.dev/api/v1/search
El body contiene los datos de búsqueda local:
{
"location": "Manchester, UK",
"keywords": ["letting agent", "estate agent"],
"radius_km": 12,
"scrape_emails": true
}
La respuesta contiene un identificador de job. El escenario solo necesita el job_id y el estado:
{
"job_id": "job_123456",
"status": "queued",
"poll_url": "/api/v1/jobs/job_123456"
}
Luego Make hace polling:
GET https://bizcollect.dev/api/v1/jobs/job_123456
Una vez completo, el resultado contiene registros de negocios estructurados:
{
"job_id": "job_123456",
"status": "completed",
"businesses": [
{
"name": "Example Lettings",
"address": "12 High St, Manchester M1 1AA",
"phone": "+44 161 555 0101",
"website": "https://examplelettings.co.uk",
"emails": ["hello@examplelettings.co.uk", "info@examplelettings.co.uk"]
}
]
}
El contrato es estable: iniciar una búsqueda, recibir un job_id, hacer polling en el endpoint del job, luego procesar JSON estructurado. Para el esquema autoritativo, usa la referencia OpenAPI en los docs de biz collect.
Paso 1: Crear el trigger
Empieza con el trigger que corresponde a tu caso de uso:
- Run once para pruebas y búsquedas puntuales.
- Schedule para prospección recurrente, como cada lunes por la mañana.
- Custom webhook cuando otro sistema o agente debe iniciar una búsqueda dinámicamente.
Para una primera versión, ejecuta el escenario manualmente y codifica de forma fija una localización y unas palabras clave en el primer módulo HTTP. Una vez estable, sustituye los valores fijos por datos de una programación, una Google Sheet de territorios o un payload de webhook.
Si quieres que el escenario acepte búsquedas dinámicas, añade un trigger Custom webhook y envía un body como:
{
"location": "Zurich, Switzerland",
"keywords": ["law firm", "tax advisor"],
"radius_km": 10,
"scrape_emails": true
}
Luego el módulo de petición a biz collect puede mapear los campos entrantes del webhook. Mantén simple el primer escenario, confirma la forma de la respuesta, y luego parametriza.
Paso 2: Añadir el módulo HTTP para /api/v1/search
Añade un módulo HTTP configurado como Make a request después del trigger. Llámalo Start biz collect Search.
Configúralo:
- URL:
https://bizcollect.dev/api/v1/search - Method:
POST - Headers: una cabecera de autorización y una cabecera content-type
- Body type: Raw, content type JSON
- Parse response: Yes, así Make expone los campos JSON
Usa estas cabeceras:
Authorization: Bearer YOUR_BIZCOLLECT_API_KEY
Content-Type: application/json
Para una búsqueda de prueba fija, usa este body JSON:
{
"location": "Miami, FL",
"keywords": ["med spa", "aesthetic clinic"],
"radius_km": 20,
"scrape_emails": true
}
Para una versión con webhook, mapea los campos de la petición en lugar de codificarlos de forma fija, por ejemplo {{1.location}} y {{1.keywords}}, donde 1 es el módulo webhook. Si tu trigger proporciona las palabras clave como cadena separada por comas, divídela primero en un array con una función split() o un módulo dedicado, porque la API espera una entrada de palabras clave clara y un array es lo más fácil de controlar.
Después de que se ejecute este módulo, tienes un bundle con job_id, status y posiblemente poll_url. Si la petición falla, comprueba la clave API, el body y los límites actuales en precios.
Paso 3: Esperar antes del primer poll
Añade un módulo Sleep después de la petición de búsqueda. Llámalo Wait Before Polling.
Fija un retardo corto, de 10 a 20 segundos. La extracción de emails requiere que la API visite los sitios web de los negocios, analice las páginas y deduplique las direcciones candidatas, así que hacer polling inmediatamente después de la petición de búsqueda suele añadir ruido sin mejorar el resultado.
Un punto de partida práctico son 15 segundos. El módulo Sleep de Make está limitado a 300 segundos por llamada, lo cual es ampliamente suficiente para una única pausa; el ciclo de polling en los pasos siguientes te da el tiempo de espera total más largo. Para búsquedas amplias, tiende hacia arriba; para pequeños jobs de enriquecimiento, bájalo.
Paso 4: Hacer polling en /api/v1/jobs/:id
Añade otro módulo HTTP llamado Poll biz collect Job.
Configúralo:
- URL:
https://bizcollect.dev/api/v1/jobs/{{job_id}}, mapeando eljob_idde la respuesta de búsqueda - Method:
GET - Headers: la misma cabecera de autorización
- Parse response: Yes
Cabeceras:
Authorization: Bearer YOUR_BIZCOLLECT_API_KEY
La respuesta de polling incluye el estado actual del job. Ramifica según ese estado en lugar de asumir que el primer poll está completo. Estados típicos a gestionar:
queuedorunning: esperar y hacer polling de nuevo.completed: procesarbusinesses.failed: detener y avisar a alguien o registrar el error.
Usa los campos de estado reales de los docs de la API como fuente de verdad.
Paso 5: Construir el ciclo de polling
Make no tiene un único módulo "cicla hasta condición", así que construye el ciclo con piezas estándar. El patrón más mantenible usa un Repeater con un número limitado de iteraciones y un Router que sale cuando el job ha terminado.
La estructura es:
- Un Repeater fijado en un número máximo de intentos, por ejemplo 20.
- En cada iteración: un módulo Sleep, luego el módulo HTTP
Poll biz collect Job. - Un Router después del poll con dos rutas.
- Ruta A, un filtro donde
statuses igual acompleted, continúa hacia el procesamiento y usa un "Stop" o un flag para que las iteraciones siguientes hagan cortocircuito. - Ruta B, un filtro donde
statuses igual afailed, enruta hacia un gestor de error.
Una forma simple de evitar iteraciones desperdiciadas es almacenar el resultado en un data store o una variable de escenario al completarse y añadir un filtro en la cima del repeater que salte el trabajo una vez fijado el flag. Con un Sleep de 15 segundos y 20 intentos, el ciclo espera unos cinco minutos antes de rendirse, lo cual se adapta a la mayoría de los jobs de extracción de emails. Ajusta ambos números al tamaño de tu búsqueda:
- Pruebas de prospección rápidas: 10 intentos a 10 segundos.
- Jobs de extracción de emails: 20 intentos a 15 segundos.
- Grandes búsquedas recurrentes: 30 intentos a 20 segundos.
El valor correcto es operativo, no teórico. Da a los jobs normales tiempo para terminar mientras haces emerger los retrasos inesperados.
Paso 6: Dividir los negocios con un Iterator
Una vez que status es completed, la respuesta contiene un array de negocios. La mayoría de los módulos de destino trabajan un bundle a la vez, así que añade un Iterator llamado Split Businesses y apúntalo al array businesses de la respuesta de poll.
Después del Iterator, cada negocio es su propio bundle con campos como name, address, phone, website y emails. Para obtener un único email principal y un conteo limpio, añade un módulo Set Variable o usa funciones inline:
primary_email = {{ first(business.emails) }}
all_emails = {{ join(business.emails; ", ") }}
email_count = {{ length(business.emails) }}
Si el escenario es específicamente para el email saliente, añade un filtro después del Iterator donde primary_email no esté vacío. Esto mantiene el CRM o la hoja de cálculo centrado en los leads sobre los que puedes actuar. Si tu equipo también llama a los prospectos, conserva los registros con un número de teléfono aunque no se encuentre ningún email, ya que la cobertura de emails siempre es parcial.
Paso 7: Enviar los leads a Google Sheets
Google Sheets es el destino más fácil porque la salida es inmediatamente visible. Añade un módulo Google Sheets "Add a row" después del Iterator.
Columnas recomendadas:
Search Job IDBusiness NameAddressPhoneWebsitePrimary EmailAll EmailsEmail CountCreated At
Mapea los valores:
Search Job ID -> {{ job_id }}
Business Name -> {{ business.name }}
Address -> {{ business.address }}
Phone -> {{ business.phone }}
Website -> {{ business.website }}
Primary Email -> {{ primary_email }}
All Emails -> {{ all_emails }}
Email Count -> {{ email_count }}
Created At -> {{ now }}
Para una estrategia de deduplicación ligera, usa el dominio del sitio web o el email principal como clave única. Como el módulo "Add a row" solo añade, agrega una comprobación "Search rows" antes de la escritura, o usa un data store indexado por dominio, si la unicidad estricta importa.
Paso 8: Enviar los leads cualificados a un CRM
Para un CRM como HubSpot o Pipedrive, el flujo común es:
- Buscar una empresa existente por dominio o sitio web.
- Si no existe coincidencia, crear la empresa.
- Si
primary_emailexiste, buscar un contacto existente por email. - Si no existe contacto, crear el contacto.
- Asociar el contacto con la empresa si tu CRM lo requiere.
Mantén la primera versión conservadora. No crees contactos duplicados solo porque un negocio tenga varios emails. Empieza con primary_email, y luego almacena opcionalmente la lista completa deduplicada en una propiedad personalizada o una nota.
Un mapeo de empresa útil:
name -> {{ business.name }}
domain -> {{ replace(replace(business.website; "https://"; ""); "www."; "") }}
phone -> {{ business.phone }}
website -> {{ business.website }}
Si tu CRM tiene reglas de datos estrictas, añade una validación antes de los módulos de creación:
- Crear contactos solo cuando
primary_emailno esté vacío. - Crear empresas solo cuando
websiteophoneesté presente. - Añadir un campo de origen como
biz collect Make scenario. - Añadir la localización de búsqueda y el conjunto de palabras clave como contexto de campaña.
Esto facilita reportar qué búsquedas locales produjeron leads útiles.
Paso 9: Añadir rutas de error y notificación
Un escenario de generación de leads suele ejecutarse de forma programada, lo que significa que los fallos silenciosos crean pipelines obsoletos. Make gestiona los errores con gestores de errores vinculados a los módulos y con rutas dedicadas para los estados de error conocidos.
Añade gestión para estos casos:
- Petición no autorizada: clave API ausente o inválida. Detener y notificar al propietario del escenario.
- Petición errónea:
locationausente,keywordsvacío oradius_kminválido. Escribir la entrada fallida en una hoja de errores. - Límite de rate o de plan: pausar el escenario y enviar una alerta con un enlace a precios.
- Job fallido: notificar vía Slack o email e incluir el
job_id. - Timeout del job: incluir el conteo de intentos y el último estado conocido.
- Ningún negocio devuelto: escribir un resultado exitoso pero vacío con los parámetros de búsqueda.
Para un resumen de ejecución compacto, agrega los negocios antes del Iterator y publica un único mensaje:
biz collect job {{ job_id }} completed.
Businesses found: {{ length(businesses) }}
With email: {{ length(filter(businesses; length(item.emails) > 0)) }}
Esto te da suficiente visibilidad para monitorizar los escenarios recurrentes sin abrir Make en cada ejecución.
Layout de escenario recomendado
Aquí está la secuencia completa de módulos para una versión práctica:
Trigger (Run once / Schedule / Webhook)
-> HTTP: Start biz collect Search
-> Repeater (max 20)
-> Sleep (15s)
-> HTTP: Poll biz collect Job
-> Router
completed -> Iterator: Split Businesses
-> Filter: primary_email is not empty
-> Google Sheets / CRM
failed -> Notify error
-> (timeout fallthrough) -> Notify timeout
Este patrón evita infraestructura a medida mientras gestiona las realidades de las API asíncronas: el trabajo puede ir a cola, los jobs pueden durar un rato, y los jobs fallidos o de larga duración necesitan una vía apta para operadores. Si estás sopesando Make frente a otras herramientas, el workflow n8n de generación de leads muestra el mismo ciclo crear-esperar-poll como nodos visuales, y la guía de las mejores herramientas de generación de leads locales en 2026 sitúa un workflow automatización-más-API entre scrapers, herramientas no-code y CRM.
Empezar a construir
El escenario Make.com de generación de leads más simple pero útil se compone de unos pocos módulos: trigger, petición HTTP, sleep, poll, router, iterator y salida. El valor viene de usar una API que devuelve datos de negocios estructurados y emails de sitios web verificados en lugar de pedirle a Make que mantenga un scraper.
biz collect está construido exactamente para este patrón: un POST para iniciar una búsqueda local, polling asíncrono hasta el completado, campos JSON estables, docs OpenAPI 3.1 y emails de contacto deduplicados extraídos de los sitios web de los negocios. Encaja con Make, n8n, Zapier, scripts, herramientas LLM y enriquecimiento CRM sin mantenimiento de navegador headless.
Puedes empezar gratis con 200 créditos de registro y sin tarjeta de crédito. Abre los docs de la API, revisa las integraciones, consulta los precios y construye hoy tu primer escenario de leads locales automatizados en Make.
Preguntas frecuentes
- ¿Cómo construyo un workflow de generación de leads en Make.com?
- Encadena cinco fases: un trigger, un módulo HTTP que hace POST de una ciudad y palabras clave hacia /v1/search, un repeater más Sleep que hace polling en /v1/jobs/:id hasta el completado, un Iterator para dividir los negocios y un módulo Google Sheets o CRM para escribir los leads. No se requiere ningún módulo de scraping.
- ¿Qué módulos de Make necesito?
- Dos módulos HTTP (búsqueda y poll), un módulo Sleep, un Repeater y un Router para el ciclo de polling, un Iterator para dividir los negocios y un módulo de destino como Google Sheets, HubSpot o Pipedrive. Módulos Set Variable opcionales limpian los campos de email.
- ¿Cómo hago polling de un job asíncrono en Make?
- Make no tiene un módulo cicla-hasta integrado, así que constrúyelo con un Repeater de conteo de iteraciones limitado, un Sleep y el módulo HTTP de poll, luego usa un Router con filtros sobre status igual a completed o failed para salir. Un sleep de 15 segundos con 20 intentos espera unos cinco minutos.
- ¿Puedo obtener emails verificados del escenario Make?
- biz collect enriquece cada negocio desde su sitio web, así que los registros pueden incluir email, sitio web, teléfono y dirección. Filtra los registros que contienen un email para quedarte solo con los leads sobre los que puedes actuar, y conserva los registros con solo teléfono cuando una llamada es el mejor canal.
- ¿Funciona también con Zapier o n8n?
- Sí. La API usa peticiones HTTP estándar, así que el mismo patrón de búsqueda-poll-itera-escribe funciona en Zapier y n8n igual que en Make. Solo la mecánica de polling difiere entre las herramientas.
- ¿Hay un plan gratuito para probar el escenario Make?
- Sí. Obtienes 200 créditos de registro más 20 créditos de acceso cada día sin tarjeta de crédito, suficientes para montar y validar el escenario completo antes de programarlo.


