Webhook en tus landing pages
La mayoría de stacks de lead gen pagan un peaje en medio: un Zap o un escenario cuyo único trabajo es mover un lead de la página a un endpoint que lo habría aceptado directamente. Cada lead paga ese salto en tareas o créditos, y cada salto es un sitio más donde un lead puede atascarse mientras un comprador espera.
La integración Webhook de LanderLab lo elimina. Cada página envía sus leads directamente a cualquier endpoint HTTPS: la URL de posting de un comprador, tu propia API de leads, el endpoint de un CRM, el postback de un tracker. Tú decides el método, el formato, las cabeceras y el body exacto, así el otro lado recibe el lead como lo pide su documentación.
Es la integración que hay detrás de la mayoría de herramientas de esta web que no tienen su propia ficha, y es la que debes usar cuando un comprador te manda una hoja de especificaciones.
Por qué un webhook directo es mejor que pagar por middleware
Un lead que va de la página a un Zap y del Zap al comprador depende de dos sistemas, y uno de ellos te lo cobra. En una oferta de mucho volumen, el plan de automatización crece con tu número de leads aunque en medio no pase nada interesante: el Zap recibe un lead y lo envía a otro sitio.
Un webhook directo es el mismo envío sin el salto. El lead va de la página al endpoint al enviarse el formulario, bajo tu control, sin nada en medio que se pause, se quede sin tareas o cambie de precios. Deja el middleware para los trabajos que necesitan varios pasos; que el webhook lleve los que no.
Envía los leads en el formato que espera el otro lado
Los compradores y las APIs son exigentes. Uno quiere un envío de formulario plano con los campos llamados exactamente como en su especificación; otro quiere JSON con el contacto anidado dentro de un objeto lead, el tracking dentro de otro, y una etiqueta de fuente y un ID de campaña fijos al lado. El webhook hace las dos cosas: una lista simple en la que marcas los campos y renombras cada clave, o un body JSON que escribes tú con objetos anidados, arrays y valores estáticos.
Los métodos cubren GET, POST y PUT, el body va como JSON o como datos de formulario URL-encoded, y las cabeceras personalizadas llevan una API key o un token, así las credenciales nunca quedan en la URL.
Campos de compliance y atribución en cada lead
LanderLab añade sus propios campos a cada lead: la URL completa de la página, la IP y el user agent del visitante, la hora del envío en UTC y la variante A/B mostrada. Son los campos que revisa un comprador cuando se disputa un lead, y los que necesitas para demostrar de dónde vino.
Añade campos ocultos con el nombre de tus parámetros de URL, como utm_campaign, gclid o el click ID de un tracker, y se guardan con el lead y se envían con él. El comprador recibe la atribución, y tú puedes juzgar cada variante por leads aceptados en lugar de por formularios rellenados sin más.
Postbacks y pings con GET
No todos los destinos quieren un body. El postback de un tracker, la URL de conversión de una red de afiliación o un simple ping reciben sus datos en la query string, y un webhook GET envía los campos mapeados justo así: el click ID con el nombre de parámetro que espera el tracker y un payout o un estado fijos al lado. Al enviarse el formulario, la conversión vuelve a la campaña que la pagó.
Cuándo usar un workflow en su lugar
Un webhook envía todos los leads de su página. Cuando solo deben ir algunos, como los leads de EE. UU. a un comprador y el resto a otro, o un seguimiento después de una Espera, Workflows (beta) de LanderLab tiene el mismo tipo de petición como nodo Petición HTTP, detrás de nodos Filtro, If y Switch, con una vista de ejecuciones que muestra el camino de cada lead y cualquier paso fallido.
En los dos casos, el lead también se guarda en la pestaña Prospectos de LanderLab, así un endpoint caído no te cuesta el lead, salvo que esté activado “Envío de prospectos compliance”, que por diseño no lo guarda.
