Cómo enviar leads de formularios de Webflow directamente a Slack

Un formulario de contacto es tan bueno como la rapidez de la respuesta que genera. El formulario en sí es la parte fácil. El vacío que te cuesta ventas es el que existe entre que alguien lo envía y un humano realmente lo ve, lo cual en la mayoría de los sitios significa un correo de notificación perdido en una bandeja de entrada compartida que nadie revisa.

Llevar ese envío a un canal de Slack cierra esa brecha y cambia la dinámica del seguimiento: un lead se convierte en un mensaje que alguien puede tomar, responder en un hilo y marcar como gestionado, en lugar de un correo electrónico que cinco personas asumen que alguien más ya respondió.

Esta guía te muestra cómo hacerlo de dos formas. La primera usa Zapier y no requiere código. La segunda recibe el webhook en tu propio gestor de rutas, lo que requiere un poco de código pero te permite verificar firmas, personalizar el enrutamiento y evitar el pago por tarea.

¿Qué necesitas para enviar los leads de Webflow a Slack?

Un formulario de Webflow publicado, un espacio de trabajo de Slack donde puedas instalar una aplicación y, dependiendo de la ruta que elijas, una cuenta de Zapier o un proyecto de Webflow Cloud. No necesitas un plan de pago de Webflow para empezar.

La lista completa antes de empezar:

• Un sitio de Webflow publicado con al menos un formulario. Haz las pruebas en el sitio publicado y no en el lienzo del Diseñador, ya que Webflow recibe los envíos en el subdominio de pruebas webflow.io y en dominios personalizados con un plan de sitio activo.
• Un espacio de trabajo de Slack donde puedas instalar aplicaciones, lo cual generalmente requiere permisos de administrador.
• Para la ruta sin código, una cuenta de Zapier. Consulta los precios actuales por tarea en la página de precios de Zapier, ya que el plan que más te conviene depende del volumen de envíos que recibas.
• Para la ruta con código, un proyecto de Webflow Cloud que ejecute Next.js, además de Node.js 22.13.0 o superior en local, el requisito mínimo de Webflow CLI 2.x. Webflow Cloud está disponible desde el plan gratuito Starter, aunque para vincular la aplicación a un dominio personalizado se requiere el plan Premium o superior.

Una vez que tengas todo esto, la decisión que determinará el resto del proceso es si prefieres que una plataforma externa gestione el envío o si prefieres recibirlo tú mismo. Aquí te explicamos cómo.

Cómo llega a Slack una notificación de lead de Webflow

Independientemente de la ruta que elijas, el proceso de fondo es el mismo: el envío de un formulario activa un webhook de Webflow, algo lo recibe, lo procesa y lo publica en un canal.

La etapa que define la calidad del resultado es la transformación de los datos. Un payload de formulario en bruto volcado en Slack es ilegible, y una notificación ilegible termina silenciada en una semana; por eso, conocer la estructura del payload es lo que te permite darle un buen formato.

Lo que Webflow envía realmente

Antes de mapear nada, observa lo que llega.

Un evento de envío de formulario llega con esta estructura, abreviada aquí ya que el payload completo también incluye schema, formElementId y localeId:

{
  "triggerType": "form_submission",
  "payload": {
    "name": "Contact Us",
    "siteId": "65427cf400e02b306eaa049c",
    "data": {
      "First Name": "Zaphod",
      "Last Name": "Beeblebrox",
      "email": "zaphod@heartofgold.ai",
      "Phone Number": 15550000000
    },
    "submittedAt": "2022-09-14T12:35:16.117Z",
    "id": "6321ca84df3949bfc6752327",
    "formId": "65429eadebe8a9f3a30f62d0"
  }
}

Hay dos detalles ahí que causan la mayoría de los errores de mapeo que veo. Las claves dentro de data son los nombres de campo legibles por humanos del Diseñador, incluyendo mayúsculas y espacios. Es "First Name", no first-name. Por lo tanto, cambiar el nombre de un campo en el Diseñador rompe cualquier mapeo posterior que hiciera referencia al nombre antiguo, así que trata los nombres de los campos como una interfaz en lugar de una etiqueta.

Tampoco asumas que cada valor es una cadena de texto. Webflow no documenta la coerción de tipos para los valores de los formularios, pero el ejemplo de la propia referencia muestra "Phone Number" sin comillas, por lo que un campo que parece numérico puede llegarte como un número. Lee de forma defensiva y convierte antes de dar formato. Una vez que puedas predecir la carga útil, los pasos de mapeo a continuación son sencillos.

5 pasos para enviar leads de formularios de Webflow a Slack con Zapier

La ruta sin código es un único Zap: Webflow como disparador instantáneo, Slack como acción y un filtro cuando más de un formulario lo alimenta. El trabajo importante es decidir qué merece una notificación y dar formato al mensaje para que siga siendo legible.

1. Decide qué merece una interrupción

Haz esto antes de construir nada. Un canal que recibe cada envío de cada formulario se convierte en ruido, y las notificaciones silenciadas son peores que no tener ninguna, porque todos asumen que están cubiertas.

Elige los formularios que representen una intención de compra real, como una solicitud de demostración o un formulario de contacto de ventas, y deja fuera las suscripciones al boletín. Si solo tienes un formulario, planea enrutar según el valor de un campo, lo cual cubrimos en el paso 5. Deberías terminar este paso con una lista escrita de qué formularios notifican y cuáles no.

2. Conecta el disparador de Webflow

En Zapier, crea un Zap con Webflow como la aplicación de disparo y Form Submission como el evento, luego autoriza tu cuenta de Webflow y elige el sitio y el formulario. Zapier registra el webhook con Webflow por ti, por eso es un disparador instantáneo y no un sondeo.

Envía una entrada de prueba real en el sitio publicado para que Zapier tenga datos de muestra con los que mapear. Este es el paso que la gente se salta, y sin él, los selectores de campo en el siguiente paso están vacíos. Una prueba exitosa muestra tus valores enviados en el registro de muestra de Zapier.

3. Mapea los campos en un mensaje de Slack

Añade Slack como la aplicación de acción, elige Send Channel Message y selecciona el canal. Ahora construye el cuerpo del mensaje a partir de los datos de muestra en lugar de soltar toda la carga útil.

Una notificación que funciona se lee de arriba a abajo en el orden en que un humano la clasifica: quién es, qué pidió, cómo contactarlos y de qué formulario proviene. Pon la dirección de respuesta en su propia línea para que sea fácil de copiar con un toque en el móvil. Cuando el mapeo es correcto, la vista previa muestra valores reales en lugar de tokens de campo.

4. Haz que el mensaje valga la pena leerlo

Slack renderiza *bold* en el texto del mensaje, así que etiquetar cada valor no cuesta nada y hace que el mensaje sea escaneable. El campo de nivel superior text es mrkdwn por defecto, por eso esto funciona sin configuración adicional.

Envíate un mensaje de prueba y léelo en un teléfono antes de dar esto por terminado, porque ahí es donde la mayoría de la gente lo verá primero. La prueba debería llegar al canal con formato, no como un muro de valores sin etiquetas.

5. Enruta por formulario o por valor

Una vez que más de un formulario alimente el Zap, añade un paso de filtro para que las consultas empresariales y las solicitudes de contacto general lleguen a canales diferentes. Filtrar por el valor de un campo, como un menú desplegable de tamaño de empresa, es lo que mantiene útil un canal compartido a medida que aumenta el volumen.

Activa el Zap y envía una entrada real más. Un Zap filtrado correctamente publica en el canal correcto o se detiene en el paso de filtro, y el historial de Zapier te muestra qué sucedió.

La ruta con código: recibe tú mismo el webhook de Webflow

Zapier es la respuesta ideal cuando el equipo de marketing gestiona el flujo de trabajo y nadie quiere ocuparse del código. Deja de serlo cuando necesitas que el cliente potencial se registre en otro lugar simultáneamente, cuando el coste por tarea empieza a importar o cuando quieres demostrar que la solicitud proviene realmente de Webflow.

Ese último punto es el argumento definitivo. Con una plataforma de automatización alojada, nunca ves la firma: la verificación ocurre dentro del proveedor, por lo que no tienes forma de probar que un mensaje dado vino de Webflow y no de cualquier persona que accedió al endpoint. Webflow firma cada webhook para que puedas comprobarlo tú mismo, y la documentación de webhooks establece el esquema. Las solicitudes incluyen un y un x-webflow-timestampx-webflow-signature, donde la firma es un HMAC SHA-256 sobre la marca de tiempo y el cuerpo original unidos por dos puntos, firmado con el secreto de tu webhook.

Añade el endpoint en la configuración de tu formulario: junto a "Enviar a", añade un Webhook e introduce la URL de tu gestor de rutas. Webflow mostrará una clave secreta solo una vez, así que cópiala antes de cerrar el cuadro de diálogo, ya que no se puede recuperar después.

Webflow recomienda utilizar el método de verificación propio de su SDK, ya que la implementación puede cambiar y una actualización del SDK te mantendrá al día. El gestor que aparece a continuación realiza la validación manualmente.

Este es el patrón a seguir en el entorno de ejecución de Workers cuando prefieres no incluir el SDK completo:

// app/api/lead-webhook/route.ts
import { NextRequest, NextResponse } from 'next/server'

const FIVE_MINUTES = 300_000

function toBytes(hex: string): Uint8Array {
  return new Uint8Array(
    (hex.match(/.{1,2}/g) ?? []).map((byte) => parseInt(byte, 16))
  )
}

async function isAuthentic(
  secret: string,
  timestamp: string,
  rawBody: string,
  signature: string
): Promise<boolean> {
  const encoder = new TextEncoder()

  const key = await crypto.subtle.importKey(
    'raw',
    encoder.encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  )

  // Webflow signs the timestamp and the raw body joined by a colon.
  const mac = await crypto.subtle.sign(
    'HMAC',
    key,
    encoder.encode(`${timestamp}:${rawBody}`)
  )

  const expected = new Uint8Array(mac)
  const provided = toBytes(signature)

  // Length must match before a constant-time compare is meaningful.
  if (expected.length !== provided.length) return false
  return crypto.subtle.timingSafeEqual(expected, provided)
}

export async function POST(request: NextRequest) {
  const timestamp = request.headers.get('x-webflow-timestamp')
  const signature = request.headers.get('x-webflow-signature')

  if (!timestamp || !signature) {
    return NextResponse.json({ error: 'Unsigned request' }, { status: 401 })
  }

  // Reject replays before doing any cryptographic work.
  if (Date.now() - Number(timestamp) > FIVE_MINUTES) {
    return NextResponse.json({ error: 'Stale request' }, { status: 401 })
  }

  // Read the body as text: the signature covers the exact bytes sent.
  const rawBody = await request.text()
  const secret = process.env.WEBFLOW_WEBHOOK_SECRET as string

  if (!(await isAuthentic(secret, timestamp, rawBody, signature))) {
    return NextResponse.json({ error: 'Bad signature' }, { status: 401 })
  }

  const event = JSON.parse(rawBody) as {
    payload: { name: string; data: Record<string, string | number> }
  }

  const fields = event.payload.data
  const lines = Object.entries(fields)
    .map(([label, value]) => `*${label}:* ${String(value)}`)
    .join('\n')

  await fetch(process.env.SLACK_WEBHOOK_URL as string, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      text: `New lead from *${event.payload.name}*\n${lines}`,
    }),
  })

  // Answer Webflow quickly; it does not need your Slack result.
  return NextResponse.json({ received: true })
}

Aquí hay cuatro puntos clave. La marca de tiempo se comprueba antes de cualquier hash, porque la guía de Webflow indica tratar una solicitud de más de cinco minutos como un posible ataque de repetición; rechazarla pronto evita que una avalancha de solicitudes obsoletas sature tu Worker con trabajo criptográfico.

El cuerpo se lee con en lugar de request.text()request.json(). Webflow firma el cuerpo tal como se envió, por lo que aplicar hash al texto sin modificar es la ruta segura: volver a serializar un objeto analizado puede alterar el orden de las claves o los espacios en blanco y romper la comprobación.

La comparación utiliza tras una protección de longitud en lugar de en dos cadenas hexadecimales, porque la comparación de cadenas termina prematuramente al encontrar el primer carácter diferente, lo que revela cuánto de una suposición era correcta. Ten en cuenta que es una extensión de Cloudflare y no un método estándar de Web Crypto, por lo que existe en el entorno de ejecución de Workers desplegado, pero no en un entorno local estándar timingSafeEqual===timingSafeEqualnext dev.

El gestor espera a la llamada de Slack antes de responder a Webflow. Esto funciona bien con volúmenes bajos de leads, pero es lo primero que hay que cambiar si Slack se vuelve lento, ya que los remitentes reintentan ante un error que no sea 2xx o una demora prolongada, lo que convierte un lead en cuatro notificaciones. Almacena ambos secretos como variables de entorno marcadas como secretas, luego despliega y envía un lead de prueba: una presentación válida se publica en Slack y devuelve un 200, mientras que una solicitud falsificada recibe un 401.

¿Qué causa que fallen las notificaciones de leads de Webflow? Consejos para solucionar problemas

Cuatro fallos cubren casi todo: la directiva del entorno de ejecución edge, un cuerpo que fue analizado antes de ser procesado con hash, un campo renombrado en el Designer y un canal que se ha convertido en ruido.

La compilación falla tras añadir el gestor de rutas

Causa: una directiva en el archivo de ruta. Webflow Cloud despliega Next.js a través del export const runtime = 'edge'adaptador OpenNext de Cloudflare, que no es compatible con el entorno de ejecución edge de Next.js.

Solución: elimina la línea. Los gestores de rutas se ejecutan en el entorno de ejecución de Workers sin ella, y el siguiente despliegue tendrá éxito.

Cada comprobación de firma falla

Causa: casi siempre el cuerpo. Si algo analiza o vuelve a serializar la solicitud antes de que le apliques el hash, es posible que la cadena ya no coincida con lo que se firmó.

Solución: aplica el hash al texto sin modificar y luego analiza. Confirma que estás leyendo con request.text() y que ningún middleware del framework está consumiendo el cuerpo primero.

Las notificaciones se detienen tras un cambio en el Designer

Causa: alguien renombró un campo del formulario. Las claves en la carga útil son los nombres de los campos, por lo que un mapeo creado para "Work Email" no produce nada una vez que cambia a "Email".

Solución: renombra con cuidado, luego actualiza el mapeo y vuelve a probar. Tratar los nombres de los campos como una interfaz en lugar de una etiqueta evita que esto vuelva a ocurrir.

El canal termina siendo ignorado en menos de dos semanas.

Causa: demasiados formularios alimentan un mismo canal, por lo que la señal se pierde. No es un fallo técnico, pero es la forma más común en que todo el esfuerzo deja de ser rentable.

Solución: divide por intención o añade un paso de filtrado para que el canal solo contenga los leads sobre los que alguien debe actuar. La señal vuelve casi de inmediato en cuanto baja el volumen.

Qué puedes construir después con Slack y Webflow Cloud

Una vez que el envío pasa por código que tú controlas, Slack se convierte en un destino más: el mismo gestor puede guardar el lead en una base de datos, enriquecerlo antes de publicarlo o enviarlo a una plataforma de correo.

Nuestra guía de registro en Mailchimp construye esa segunda ruta por completo usando la misma estructura de gestor de rutas. Para las conexiones que se explican aquí sin código, consulta la integración de Webflow y Slack y la integración de Webflow y Zapier.

Para una personalización más profunda de lo que permiten estas integraciones, la documentación para desarrolladores de Webflow cubre los gestores de rutas, la verificación de webhooks y el resto del entorno de ejecución de Webflow Cloud.