Módulo 8: Proyecto — Hub de Integraciones

Los Puntos de Entrada

Siguiente →

Descripción de la cápsula

Tienes el plano (cápsula 02). Empezamos a construir — por la primera capa: los puntos de entrada.

Esta capa tiene una sola responsabilidad, y conviene repetirla porque es la disciplina que hace funcionar todo el hub: cada punto de entrada traduce lo que llega por su canal al "lead normalizado", y nada más. No registra, no avisa, no decide. Recibe → traduce → entrega. Es un traductor, no un procesador.

En esta cápsula construyes los tres traductores del hub de Norte Digital — el del formulario web, el de Calendly, el del email — y, lo más importante, los haces converger: que los tres caminos distintos terminen en un solo punto desde el cual el núcleo continúa, sin saber por cuál de los tres llegó el lead.

Lo que vas a aprender

Al terminar esta cápsula serás capaz de:

  • ✅ Construir un punto de entrada para un webhook (formulario)
  • ✅ Construir un punto de entrada para Calendly
  • ✅ Construir un punto de entrada para email (Gmail)
  • ✅ Traducir cada uno al "lead normalizado" — el formato común
  • ✅ Hacer converger los tres caminos en uno solo
  • ✅ Mantener la disciplina: las entradas solo traducen

El principio: cada entrada es un traductor

Antes de construir, fija la regla — porque vas a sentir la tentación de romperla:

Mientras construyes el punto de entrada del formulario, vas a pensar "ya que tengo el email aquí, registro el lead en HubSpot de una vez". No lo hagas. Ese es el primer paso hacia el hub "espagueti" de la cápsula 02.

El punto de entrada termina su trabajo cuando ha producido un lead normalizado con los seis campos. Punto. Lo que pasa después es del núcleo — y el núcleo es uno solo para los tres canales.

Recordatorio del formato común (cápsula 02):

name · email · company · message · source_channel · date

Los tres traductores que vas a construir terminan todos produciendo exactamente esta estructura.

Punto de entrada 1: el formulario web (Webhook)

El canal más directo. Un formulario en la web de la agencia manda sus datos a un Webhook Trigger (G2-M01).

Construcción

  1. Webhook Trigger — n8n te da una URL; el formulario web la usa como destino
  2. Set — el traductor. Mapea lo que llega del formulario al lead normalizado: 
    name           = {{ $json.body.name }}
email          = {{ $json.body.email.toLowerCase().trim() }}
company        = {{ $json.body.company || 'Sin especificar' }}
message        = {{ $json.body.message || 'Sin mensaje' }}
source_channel = form
date           = {{ $now.toISO() }}

Mira el output real del webhook — la estructura exacta ($json.body.x o $json.x) depende de cómo el formulario envíe los datos. Como siempre: no adivines, observa.

El source_channel es texto fijo form — este traductor sabe quién es. Los valores por defecto (|| 'Sin especificar') protegen contra campos opcionales que el formulario no siempre manda.

Punto de entrada 2: Calendly

Una reserva en Calendly también es un lead — alguien que quiere hablar con la agencia. El traductor reusa todo lo del Módulo 7.

Construcción

  1. Calendly Trigger — suscrito a invitee.created (cápsula 04 del M07)
  2. Set — el traductor. Aplana el payload de Calendly (cápsula 05 del M07) al lead normalizado: 
    name           = [nombre del invitee]
email          = [email del invitee, normalizado]
company        = [si una pregunta del formulario de reserva la captura, si no: 'Sin especificar']
message        = [la respuesta de "¿de qué quieres hablar?", o 'Reservó una llamada']
source_channel = calendly
date           = {{ $now.toISO() }}

Aquí se ve el poder del formato común: el payload de Calendly es completamente distinto al del formulario — anidado, con invitee, con respuestas en lista. Pero el traductor lo dobla hacia la misma estructura de seis campos. El núcleo nunca verá esa diferencia.

Punto de entrada 3: el email de contacto (Gmail)

Un correo a hola@nortedigital.com también es un lead. El traductor reusa el Gmail Trigger del Módulo 2.

Construcción

  1. Gmail Trigger — con un filtro para los correos a la dirección de contacto (cápsula 04 del M02)
  2. Set — el traductor: 
    name           = [extraído del campo "from" del correo]
email          = [extraído del "from", normalizado]
company        = Sin especificar
message        = {{ $json.snippet }}   (o el cuerpo del correo)
source_channel = email
date           = {{ $now.toISO() }}

El email es el canal más pobre en datos estructurados — no trae "empresa", el nombre viene mezclado en el campo from. Aquí el formato común muestra otra virtud: donde un canal no tiene un dato, el traductor pone el valor por defecto. El núcleo recibe los seis campos siempre, aunque algunos vengan con "Sin especificar". Un campo faltante nunca rompe el flujo aguas abajo.

Hacer converger los tres caminos

Ahora tienes tres traductores, cada uno produciendo un lead normalizado. Necesitas que los tres lleguen al mismo núcleo. Dos formas:

Forma A: nodo Merge (un solo workflow)

Si construiste los tres en un mismo workflow, un nodo Merge une los tres caminos en uno. Después del Merge, hay un solo flujo — el núcleo — que recibe el lead normalizado venga del traductor que venga.

El Merge es el "cuello" del reloj de arena (cápsula 01): tres caminos entran, uno sale. A partir de ahí, un solo conjunto de nodos procesa y distribuye.

Forma B: subworkflow (varios workflows)

Cada traductor es un workflow propio que, al terminar, invoca un workflow "núcleo + distribución" común, pasándole el lead normalizado. El núcleo existe una sola vez de verdad.

Para este capstone, construye con Merge — es más visual y entiendes el flujo completo de un vistazo. La cápsula 07 retoma el subworkflow como evolución de producción.

El resultado, en cualquiera de las dos formas:

Webhook (formulario)  → Set traductor ─┐
Calendly Trigger      → Set traductor ─┼→ [MERGE] → NÚCLEO →...
Gmail Trigger         → Set traductor ─┘

La prueba de esta capa: tres entradas, un formato

Antes de seguir al núcleo, verifica que la capa de entrada cumple su contrato:

Dispara cada uno de los tres canales (un envío del formulario, una reserva de Calendly, un correo). Después del Merge, mira el output. Los tres deben producir un objeto con exactamente los mismos seis campos, con los mismos nombres. Si el del formulario tiene email pero el de Calendly tiene correo — la capa de entrada falló su contrato, y hay que arreglarlo aquí, no más adelante.

Si los tres outputs son idénticos en estructura, la capa de entrada está lista. El núcleo podrá trabajar sin saber de dónde vino nada.

Trampas comunes

Trampa 1: Meter lógica de negocio en un traductor

Qué pasa: "Ya que estoy, registro en HubSpot aquí". Esa lógica ahora solo aplica a ese canal.

Cómo evitar: El traductor solo traduce. Termina cuando produjo el lead normalizado.

Trampa 2: Que los traductores produzcan campos distintos

Qué pasa: Uno produce email, otro correo, otro mail. El núcleo recibe tres formatos y la arquitectura se cae.

Cómo evitar: Los seis campos del formato común, con nombres idénticos, en los tres traductores. Sin excepción.

Trampa 3: No poner valores por defecto donde un canal es pobre

Qué pasa: El email no trae "empresa", el traductor no pone default, y el campo llega undefined al núcleo.

Cómo evitar: Donde un canal no tiene un dato, el traductor pone el valor por defecto ('Sin especificar'). El núcleo siempre recibe los seis campos llenos.

Trampa 4: Olvidar source_channel

Qué pasa: Los traductores no marcan de dónde vino el lead. Después es imposible saber qué canal funciona mejor.

Cómo evitar: Cada traductor pone su source_channel como texto fijo. Es gratis y vale oro para reportes.

Trampa 5: No verificar el contrato antes de seguir

Qué pasa: Avanzas al núcleo y a mitad de camino descubres que un traductor produce un formato distinto.

Cómo evitar: Haz "la prueba de esta capa" — dispara los tres, compara los outputs. Que sean idénticos en estructura antes de tocar el núcleo.

Ejercicio: construye la capa de entrada

Objetivo: los tres traductores produciendo un formato común idéntico.

Tu tarea

  1. Construye los tres puntos de entrada en un solo workflow:
    • Webhook Trigger → Set traductor (source_channel = form)
    • Calendly Trigger → Set traductor (source_channel = calendly)
    • Gmail Trigger → Set traductor (source_channel = email)
  2. Cada Set produce los seis campos del lead normalizado, con nombres idénticos.
  3. Une los tres con un nodo Merge.
  4. La prueba del contrato: dispara los tres canales (envío de formulario, reserva, correo). Después del Merge, confirma que los tres outputs tienen la misma estructura de seis campos.
Ver pistas
  • Si no tienes un formulario web real, puedes simular el webhook mandándole una petición de prueba con los campos esperados.
  • Para Calendly y Gmail, reusa lo que ya hiciste en los Módulos 7 y 2 — solo cambia que el Set ahora produce el formato común, no el formato específico de ese módulo.
  • La prueba del paso 4 es la más importante: si los tres no coinciden en estructura, arréglalo aquí. No avances con el contrato roto.

Resumen y siguiente paso

  • La capa de entrada tiene una sola responsabilidad: traducir lo que llega a un lead normalizado — recibir, traducir, entregar
  • Cada punto de entrada es un traductor, no un procesador — no registra, no avisa, no decide
  • Construiste tres: Webhook (formulario), Calendly Trigger, Gmail Trigger — cada uno con un Set que produce los seis campos comunes
  • El formato común dobla payloads completamente distintos hacia la misma estructura — el núcleo nunca verá la diferencia
  • Donde un canal es pobre en datos, el traductor pone valores por defecto — el núcleo siempre recibe los seis campos
  • Los tres caminos convergen con un nodo Merge (para este capstone) — el "cuello" del reloj de arena
  • Verifica el contrato antes de seguir: los tres outputs deben ser idénticos en estructura
  • 5 trampas: lógica de negocio en un traductor, campos con nombres distintos, faltar valores por defecto, olvidar source_channel, no verificar el contrato

Antes de avanzar deberías poder:

  • Construir un punto de entrada que traduce a un formato común
  • Hacer converger varios caminos con Merge
  • Verificar que los traductores cumplen el contrato

Lo que sigue (cápsula 04):

Los tres caminos convergen en un solo punto, todos con el mismo formato. Ahí empieza el núcleo de procesamiento — el "cerebro" del hub: donde el lead se deduplica, se enriquece y se enruta. Una sola copia, para los tres canales.

Recursos adicionales

  1. n8n Merge node Docs - Para hacer converger las entradas.
  2. n8n Webhook Trigger Docs - El punto de entrada del formulario.
  3. Revisa los Módulos 2 (Gmail Trigger) y 7 (Calendly Trigger) — los reusas aquí como traductores.

Creado: Mayo 14, 2026 Versión: 1.0

← AnteriorArquitectura del HubSiguiente →El Núcleo de Procesamiento