Lección 13 · Conecta Cualquier Página Web con GHL
Qué aprendes
Conectar una página web externa con GHL para que cada lead que rellene su formulario entre en tu subcuenta y dispare tu seguimiento — por inbound webhook o por formulario embebido.
El problema
Creas una landing fuera de GHL (su caso: con Claude, incluso en local, sin dominio todavía). Alguien rellena su formulario… y ese lead no existe para GHL: ni contacto, ni seguimiento de WhatsApp, ni nada. Hay que puentearlo.
Vía 1 — Inbound webhook (su vía actual para formularios)
- En el workflow que recibirá los leads (su seguimiento de lead forms): añade un trigger nuevo → Inbound Webhook. GHL te da una URL única: trátala como un conector — quien envíe datos a esa URL, mete un lead en tu automatización.
- Dile a la web que envíe ahí los datos del formulario (en la demo se lo pide a Claude: «todos los leads, mándamelos a este webhook»).
- Envía un lead de prueba real desde la landing.
- En el trigger, Mapping Reference → Select Reference: elige esa solicitud de prueba. Verás los campos tal como llegaron (nombre, empresa, puesto, email…) con fecha y hora.
- ⭐ Paso que no existe con formularios nativos: crear el contacto. Al no ser un formulario de GHL, el contacto NO se guarda solo. Añade la acción de crear contacto y mapea campo a campo: campo de GHL (First Name, Email…) ← valor personalizado (Custom Value) del inbound webhook correspondiente.
- Guarda: desde ahí, cada envío crea el contacto y sigue el workflow (seguimiento, agente, lo que haya detrás).
Vía 2 — Formulario nativo embebido
- Crea el formulario dentro de GHL (Sites → Formularios).
- Integrar → Embed Code: copias el código.
- Lo pegas en la web externa (él se lo da a Claude: «cambia el formulario por este de GoHighLevel»).
- El trigger del workflow pasa a ser Form Submitted sobre ese formulario — y aquí no hay que crear el contacto: al ser nativo, GHL lo guarda automáticamente.
¿Cuál usa él, y por qué?
| Formularios de landing | Calendarios | |
|---|---|---|
| Su elección | Webhook | Embed |
| Motivo | El formulario de GHL «queda mal» dentro de un diseño hecho a medida: adaptarlo es trabajo manual en el constructor de GHL, sin un Claude que lo haga por ti. Con el webhook, la landing conserva su diseño y solo hay que mapear campos. | El embed de calendario sí lo usa mucho: pega el código del calendario de GHL en su landing externa y la reserva funciona nativa. |
Errores típicos
- Olvidar la acción de crear el contacto en la vía webhook: la automatización corre… sin nadie a quien enviarle el WhatsApp.
- Mapear sin una solicitud de prueba real: mapea siempre desde el Mapping Reference con datos de verdad, no de memoria.
- Tratar la URL del webhook como un secreto menor: es la puerta de entrada de leads a tu CRM; quien la tenga puede inyectar contactos.
Práctica
- [ ] Un workflow con trigger Inbound Webhook y su URL localizada.
- [ ] Una landing externa (aunque sea en local) enviando un lead de prueba que aparece en el Mapping Reference.
- [ ] Contacto creado por mapeo y comprobado en la sección Contactos.
- [ ] Un calendario de GHL embebido en una página externa y reserva de prueba hecha.
Preguntas de repaso
- ¿Cuál es la diferencia práctica clave entre las dos vías? → Con el embed nativo, el contacto se crea solo. Con el webhook, debes añadir la acción de crear el contacto y mapear cada campo desde la solicitud recibida.
- ¿Por qué prefiere el webhook para formularios y el embed para calendarios? → Diseño: el formulario de GHL desentona en una landing a medida y cuesta adaptarlo; el calendario embebido, en cambio, funciona bien tal cual y se integra nativo.
Vigencia
El inbound webhook y el embed son mecanismos estables de GHL; su flujo de trabajo (landing generada con Claude + webhook) refleja sus herramientas actuales.