Cómo automatizar flujos de trabajo de formularios y CMS de Webflow con n8n en Webflow Cloud

Un formulario nativo de Webflow gestiona un contacto general o una suscripción al boletín sin ayuda alguna. El trabajo se acumula después de eso. Alguien copia la entrada en una colección del CMS, avisa al equipo, añade el contacto a una lista, y nadie sabe qué envíos se han gestionado y cuáles se han pasado por alto y olvidado.

Un formulario que registra el sitio y un formulario que posee tu propio código se comportan de forma diferente una vez que se pulsa el botón. Cuando el envío pasa a través de un gestor de rutas que has escrito, tú decides qué se valida y qué se firma antes de que se reenvíe nada, y n8n se encarga del resto.

Una única ruta POST en una aplicación Next.js en Webflow Cloud acepta envíos desde un componente de formulario, firma la carga útil con un secreto compartido y la entrega a un nodo Webhook de n8n.

¿Qué necesitas para ejecutar un flujo de trabajo de formularios de n8n en Webflow?

Necesitas seis requisitos previos para esta construcción.

Ten estos elementos listos antes de configurar el flujo de trabajo de n8n y la aplicación de Webflow Cloud:

• Sitio de Webflow en cualquier plan: Webflow Cloud se envía desde el nivel Starter gratuito; Premium solo importa cuando la aplicación se monta en tu dominio personalizado.
• Instancia de n8n sobre HTTPS: Autohospedada o n8n Cloud, siempre que la instancia sea accesible públicamente y puedas crear y activar flujos de trabajo.
• Node.js y npm: Webflow Cloud solo admite npm, por lo que cada instalación en esta compilación utiliza npm install.
• Repositorio de la aplicación: Mantén el código del andamiaje y de la ruta juntos en el repositorio que utilices para esta compilación.
• Acceso a la API de Webflow: n8n lo utiliza cuando el flujo de trabajo realiza solicitudes a la API REST de Webflow. Mantén los detalles de acceso fuera de la aplicación.
• Cadena secreta compartida: Cualquier valor aleatorio largo que la ruta utilice para firmar cada carga útil y que n8n utilice para verificarla.

Webflow Cloud está disponible desde el plan de sitio Starter gratuito, mientras que montar la aplicación terminada en un dominio personalizado requiere Premium o superior. Con estos requisitos previos, la construcción depende de crear un webhook de n8n activo antes de configurar la aplicación para enviarle los envíos.

6 pasos para automatizar flujos de trabajo de formularios y CMS de Webflow con n8n en Webflow Cloud

Un flujo de trabajo de n8n activo proporciona la URL de producción de la que dependen todos los pasos posteriores. El gestor de rutas de Next.js valida y firma el envío antes de enviarlo a ese webhook con las API compatibles con Cloudflare Workers.

Crea primero el flujo de trabajo receptor, luego configura, codifica, despliega y prueba la aplicación de Webflow Cloud que reenvía cada envío de formulario.

1. Crea el flujo de trabajo de n8n que recibe los envíos

Primero, crea el flujo de trabajo de recepción en n8n. La ruta depende de la URL de producción de un nodo Webhook activo, por lo que n8n debe estar escuchando antes de que puedas probar nada en Webflow.

La documentación de n8n cubre la configuración del nodo Webhook que usamos aquí: en n8n, añade un nodo Webhook como disparador, establece el método HTTP en POST, asígnale una ruta que puedas identificar fácilmente en los registros (algo como ) y utiliza la opción de cuerpo sin procesar (raw body) para que los bytes que n8n cifra sean exactamente los mismos que firmó la ruta.webflow-forms

Configura el nodo para que responda de inmediato; un visitante nunca debería tener que esperar a que una solicitud al CMS reciba confirmación.

Después del disparador, añade un nodo de código que lea la X-Signature-256 cabecera y vuelva a calcular un HMAC-SHA256 del cuerpo sin procesar con el secreto compartido. Utiliza una comparación de tiempo constante para las firmas; === no es adecuada. Detén la ejecución si no coinciden.

Verificación de la firma y la vigencia

Una vez validada la firma, rechaza cualquier valor de receivedAt que esté fuera de un breve margen de tiempo para evitar que un cuerpo y una firma capturados puedan ser reutilizados más tarde. Todo lo que sigue a ese filtro es la automatización que realmente buscabas: un nodo que escribe en el CMS de Webflow.

Vale la pena saber esto antes de construirlo manualmente: n8n incluye un nodo de acción nativo de Webflow que cubre la creación, eliminación, obtención y actualización de elementos, además de un nodo de disparador de Webflow, y ambos aceptan un token de acceso a la API u OAuth2. En n8n Cloud, esa credencial se obtiene con un clic en el navegador en lugar de tener que almacenar y rotar un token tú mismo.

Usa el nodo integrado a menos que necesites algo que no cubra; en ese caso, un nodo de solicitud HTTP contra la API REST de Webflow es tu vía de escape, o un nodo que envíe mensajes a tu chat de equipo, lo que requiera el flujo de trabajo. Yo mapeo cada campo del formulario para el paso del CMS en el cuerpo JSON del nodo de solicitud HTTP, de modo que la ruta solo pase los datos del envío a través de la aplicación.

Mantén el paso de la API del CMS y la notificación en ramas separadas para que una caída en el chat nunca bloquee la rama del CMS.

Activa el flujo de trabajo y luego copia la URL de producción del nodo Webhook para el entorno de Webflow Cloud. La URL de prueba solo escucha mientras el nodo está abierto en el editor, por lo que una ruta que apunte a ella funcionará durante una demostración y se detendrá en cuanto cierres la pestaña. Ahora deberías tener una URL de webhook de producción activa y lista para el entorno de Webflow Cloud.

2. Prepara la estructura de la aplicación Next.js con npm

Prepara una aplicación Next.js básica con npm y sin adaptadores ni paquetes adicionales. Usa una versión de Next.js compatible con Webflow Cloud y constrúyela solo con npm, para que un repositorio que contenga un pnpm-lock.yaml o yarn.lock ya esté fuera del camino soportado antes del primer commit.

Después de preparar la aplicación compatible, ejecuta estos comandos desde el directorio del proyecto:

cd webflow-n8n-forms
npm run dev

Ahora tienes un proyecto con App Router que utiliza una versión compatible de Next.js y npm. Mantén next.config sin cambios. Webflow Cloud inyecta la ruta de montaje durante la compilación y realiza el despliegue a través del adaptador OpenNext Cloudflare por su cuenta, y la página de "trae tu propia aplicación" lo deja claro: "Sin adaptador, sin ruta base, sin wrangler.json".

Con el servidor de desarrollo en marcha, localhost:3000 muestra la página predeterminada de Next.js y el proyecto está listo para enviarse a su repositorio remoto.

3. Crea el proyecto en Webflow Cloud y configura sus variables de entorno

Crea un proyecto en Webflow Cloud para el sitio, conecta el repositorio de la aplicación y crea un entorno con una ruta de montaje como /app. La ruta de montaje del entorno determina lo que el formulario obtiene más adelante, mientras que sus variables proporcionan la configuración de la aplicación desplegada. Webflow Cloud pone las variables, tanto secretas como públicas, a disposición del proceso de compilación y de la aplicación desplegada en tiempo de ejecución.

El panel de variables de entorno muestra cada variable junto al interruptor de secreto. Este interruptor distingue el valor de firma compartido de la configuración que puede aparecer en el paquete del navegador desplegado.

Añade las siguientes variables al entorno de Webflow Cloud:

• N8N_WEBHOOK_URL: Usa la URL de webhook de producción, incluyendo su ruta; coloca la URL de prueba en .env.local para el trabajo local.
• N8N_SHARED_SECRET: Usa la misma cadena HMAC larga y aleatoria en ambos sistemas, márcala como secreta y refléjala en .env.local.
• ALLOWED_ORIGIN: Establece el esquema y el host del sitio, sin ruta, para las comprobaciones de origen; omítelo en local para aceptar localhost.
• NEXT_PUBLIC_BASE_PATH: Haz que coincida exactamente con la ruta de montaje del entorno, como /app; déjalo vacío en local porque next dev sirve desde la raíz.

Ya deberías tener configurados el webhook de producción, el secreto compartido de firma, el origen permitido y la ruta de montaje visible para el navegador antes de crear el Route Handler.

4. Escribe el Route Handler que firma y reenvía a n8n

Escribe un manejador estándar de la web sin la directiva edge, tal como requiere el adaptador de Cloudflare para OpenNext. La documentación de "bring-your-own-app" todavía incluye una línea que te indica añadir export const runtime = 'edge' a las rutas de API, y esa línea genera una compilación defectuosa: Webflow Cloud despliega Next.js a través del adaptador de Cloudflare de OpenNext, el cual no es compatible con el runtime edge de Next.js.

La confusión proviene de que una misma palabra significa dos cosas distintas. Webflow Cloud se ejecuta en Cloudflare Workers, una plataforma edge, mientras que runtime = 'edge' selecciona el objetivo del runtime edge de Next.js, algo totalmente distinto que OpenNext no puede compilar. Un Route Handler sin exportación de runtime termina en Workers de todos modos.

Esta ruta POST accesible desde el navegador carece de autenticación y limitación de tasa. También deja sin límite las ejecuciones de n8n, las escrituras en el CMS, las notificaciones y el gasto resultante. La comprobación de Origin y el honeypot ofrecen un filtrado limitado.

Un cliente que no sea un navegador puede falsificar la cabecera y enviar repetidamente un honeypot vacío. Antes de considerar la ruta lista para producción, añade un límite de tasa documentado y compatible con la plataforma, además de un tope para las ejecuciones o escrituras en el CMS. Añade también una puerta de autenticación si el acceso al formulario es privado.

Comprobación de filtración de secretos: N8N_SHARED_SECRET es solo para el servidor; NEXT_PUBLIC_BASE_PATH es intencionadamente visible para el navegador y nunca debe contener credenciales. El estado de OAuth no es aplicable porque esta compilación no contiene ningún flujo de autorización OAuth.

Crea con este contenido:app/api/forms/route.ts

// app/api/forms/route.ts
import { NextResponse } from 'next/server';

type Payload = Record<string, string>;

async function hmacHex(secret: string, message: string): Promise<string> {
  const encoder = new TextEncoder();
  const key = await crypto.subtle.importKey(
    'raw',
    encoder.encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign'],
  );
  const signature = await crypto.subtle.sign('HMAC', key, encoder.encode(message));
  return Array.from(new Uint8Array(signature))
    .map((byte) => byte.toString(16).padStart(2, '0'))
    .join('');
}

export async function POST(request: Request) {
  const webhookUrl = process.env.N8N_WEBHOOK_URL;
  const secret = process.env.N8N_SHARED_SECRET;
  const allowedOrigin = process.env.ALLOWED_ORIGIN;

  if (!webhookUrl || !secret) {
    return NextResponse.json({ error: 'Automation is not configured' }, { status: 500 });
  }

  const origin = request.headers.get('origin');
  if (allowedOrigin && origin !== allowedOrigin) {
    return NextResponse.json({ error: 'Forbidden' }, { status: 403 });
  }

  let data: Payload;
  try {
    const parsed: unknown = await request.json();
    if (
      typeof parsed !== 'object' ||
      parsed === null ||
      Array.isArray(parsed) ||
      !Object.values(parsed).every((value) => typeof value === 'string')
    ) {
      return NextResponse.json(
        { error: 'Body must be an object with string fields' },
        { status: 400 },
      );
    }
    data = parsed as Payload;
  } catch {
    return NextResponse.json({ error: 'Body must be JSON' }, { status: 400 });
  }

  // Honeypot: real visitors never see this field, so a value means a bot.
  if (data.website) {
    return NextResponse.json({ ok: true });
  }

  if (!data.email || !data.email.includes('@')) {
    return NextResponse.json({ error: 'A valid email is required' }, { status: 400 });
  }

  const body = JSON.stringify({
    ...data,
    source: 'webflow-cloud',
    receivedAt: new Date().toISOString(),
  });

  const signature = await hmacHex(secret, body);

  let upstream: Response;
  try {
    upstream = await fetch(webhookUrl, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'X-Signature-256': signature,
      },
      body,
    });
  } catch {
    return NextResponse.json(
      { error: 'Automation did not accept the submission' },
      { status: 502 },
    );
  }

  if (!upstream.ok) {
    return NextResponse.json(
      { error: 'Automation did not accept the submission' },
      { status: 502 },
    );
  }

  return NextResponse.json({ ok: true });
}

El manejador firma cada solicitud y deja la verificación a n8n, por lo que no hay comparación de tiempo constante en este archivo: aquí no se compara ninguna firma. La firma solo necesita crypto.subtle, que se comporta igual en ambos sitios; el lado que verifica reside en n8n, donde Node es Node.

El campo honeypot y la comprobación de Origin implementan los filtros limitados descritos anteriormente. Con n8n activo y el servidor de desarrollo en marcha, curl -X POST localhost:3000/api/forms -H 'Content-Type: application/json' -d '{"email":"test@example.com","name":"Test"}' devuelve {"ok":true} y aparece una nueva ejecución en n8n.

5. Añade el componente de formulario que envía datos a través de la ruta de montaje

Configura el formulario de la aplicación montada para que envíe los datos a ${basePath}/api/forms. Una solicitud /api/forms simple va a la raíz del sitio.

Webflow Cloud gestiona la ruta de montaje para el enrutamiento del lado del servidor durante la compilación, pero una petición fetch que se ejecuta en el navegador va exactamente a donde le digas, y la documentación de "bring-your-own-app" lo deja claro: "Las llamadas fetch del lado del cliente deben incluir manualmente la ruta base". Bajo next dev la ruta base está vacía y /api/forms funciona, que es exactamente cómo este error se oculta hasta el despliegue.

El componente cliente que envía los campos, app/components/LeadForm.tsx, tiene este aspecto:

// app/components/LeadForm.tsx
'use client';

import { useState, type FormEvent } from 'react';

const basePath = process.env.NEXT_PUBLIC_BASE_PATH ?? '';

export function LeadForm() {
  const [state, setState] = useState<'idle' | 'sending' | 'sent' | 'failed'>('idle');

  async function handleSubmit(event: FormEvent<HTMLFormElement>) {
    event.preventDefault();
    setState('sending');

    const form = event.currentTarget;
    const payload = Object.fromEntries(new FormData(form).entries());

    try {
      // The mount path matters: a bare /api/forms reaches the parent
      // Webflow site, not this app.
      const res = await fetch(`${basePath}/api/forms`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify(payload),
      });

      setState(res.ok ? 'sent' : 'failed');
      if (res.ok) form.reset();
    } catch {
      setState('failed');
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="name">Name</label>
      <input id="name" name="name" type="text" required />

      <label htmlFor="email">Email</label>
      <input id="email" name="email" type="email" required />

      <label htmlFor="message">Message</label>
      <textarea id="message" name="message" required />

      <input
        name="website"
        type="text"
        tabIndex={-1}
        autoComplete="off"
        aria-hidden="true"
        style={{ display: 'none' }}
      />

      <button type="submit" disabled={state === 'sending'}>
        {state === 'sending' ? 'Sending' : 'Send'}
      </button>

      {state === 'sent' && <p>Thanks, your message is on its way.</p>}
      {state === 'failed' && <p>Something went wrong. Please try again.</p>}
    </form>
  );
}

Importa LeadForm en app/page.tsx en lugar del código estándar. El campo website oculto es el honeypot que comprueba la ruta; se sitúa fuera del orden de tabulación y fuera del árbol de accesibilidad.

La gente lo deja vacío, mientras que un bot de scraping de formularios suele rellenarlo. Los valores de NEXT_PUBLIC_ se insertan en línea durante la compilación, por eso tienes que establecer la variable en el entorno de Webflow Cloud antes de que se ejecute la compilación.

El envío en local debería mostrar la línea de éxito y producir una ejecución en n8n que contenga el nombre, el correo electrónico y el mensaje.

6. Despliega y prueba el flujo de trabajo de principio a fin

Haz commit y push, luego compila el entorno en Webflow Cloud. Los registros de compilación ocultan el valor secreto. Un registro que muestre N8N_SHARED_SECRET como oculto confirma el comportamiento esperado. Cuando la compilación termine, abre la aplicación en su ruta de montaje (/app) y envía el formulario con una dirección de correo electrónico real.

Empieza por la pestaña Red del navegador, ya que sus resultados muestran si la solicitud llegó a la ruta. Un POST a /app/api/forms debería devolver un 200.

Si falta el prefijo, corrige la configuración de la ruta base que utiliza el componente de formulario. Luego, rastrea la solicitud a través de la lista de ejecuciones de n8n y confirma que la rama del CMS de destino se completó correctamente.

Montar la aplicación en tu dominio personalizado requiere un plan Premium o superior. Una vez que se active, ALLOWED_ORIGIN debe coincidir con el origen del dominio personalizado, o la ruta devolverá un 403 a tus visitantes.

Ahora deberías tener un envío que viaja desde una página de tu dominio, a través de una ruta de tu propiedad, hacia una ejecución de n8n y finalmente a un paso del CMS y una notificación.

¿Qué hace que un flujo de trabajo de formulario de n8n falle en Webflow Cloud?

Un error 404 tras el despliegue suele apuntar a la ruta de montaje, mientras que un 500 apunta a las variables de entorno. Los errores de compilación suelen indicar una directiva de tiempo de ejecución o un módulo nativo de Node no compatible.

Empieza por el estado HTTP o el error de compilación, ya que esto acota el fallo antes de que cambies cualquier configuración.

La compilación falla justo después de añadir la ruta

Causa: Es probable que el proyecto contenga runtime = 'edge'. Webflow Cloud se ejecuta en Cloudflare Workers, pero eso no significa que el Route Handler deba seleccionar el destino de tiempo de ejecución edge de Next.js por separado.

Webflow Cloud despliega Next.js a través del adaptador OpenNext Cloudflare, que no admite ese destino, por lo que la directiva puede romper la compilación aunque el destino sea una plataforma edge.

Solución: Busca runtime = 'edge' en todo el proyecto, incluyendo cualquier ruta, diseño o página. Elimina todas las copias, mantén el manejador con estándares web y vuelve a desplegar. Un Route Handler sin exportación de tiempo de ejecución sigue aterrizando en Workers a través del adaptador de la plataforma.

Al enviar el formulario se obtiene un 404 en la aplicación montada, pero el mismo formulario funciona con next dev

Causa: Es probable que a la solicitud del navegador le falte la ruta de montaje de Webflow Cloud. En next dev, la ruta base está vacía y /api/forms llega a la ruta local, pero el navegador desplegado envía una solicitud directa a la raíz del sitio en lugar de a la aplicación montada. El enrutamiento del lado del servidor no soluciona una petición fetch del lado del cliente tras el despliegue.

Solución: Comprueba la solicitud en la pestaña de red. Si no empieza por /app/api/forms, configura process.env.NEXT_PUBLIC_BASE_PATH para que coincida exactamente con la ruta de montaje, con una barra inclinada al principio y sin ninguna al final. Inicia una nueva compilación porque los valores de NEXT_PUBLIC_ se integran al compilar el paquete, y mantén la ruta de montaje y la variable sincronizadas manualmente.

La ruta devuelve un 500 en producción y n8n no registra ninguna ejecución

Causa: Falta una variable de ruta necesaria en el entorno de Webflow Cloud, por lo que la ejecución falla. Las variables pertenecen al entorno en el que las introdujiste, y un valor en .env.local solo existe en tu máquina porque ese archivo nunca se despliega. La ruta muestra cualquier rechazo ascendente como un 502, por lo que un 500 apunta a la configuración en el lado de Webflow Cloud y un 502 apunta a n8n.

Solución: Confirma que ambos nombres de variable coinciden con el código carácter por carácter, incluyendo mayúsculas y minúsculas. Los secretos se ocultan en los registros de compilación, por lo que no puedes usar el registro para inspeccionar el valor almacenado; en caso de duda, genera un nuevo secreto, introdúcelo tanto en Webflow Cloud como en el nodo de código de n8n y vuelve a desplegar.

Para una respuesta 502, confirma que el flujo de trabajo está activo y que la configuración del webhook utiliza la URL de producción del nodo Webhook. Luego, vuelve a enviar y observa cómo se completa la lista de ejecuciones.

El despliegue falla con un error de resolución de módulo para node:fs, aunque next dev funciona correctamente

Causa: Webflow Cloud fija una fecha de compatibilidad de Workers que no proporciona node:fs, por lo que una importación en la ruta o en una de sus dependencias no puede resolverse en la compilación desplegada. El next dev local se ejecuta en Node, donde node:fs siempre existe, por lo que todas las pruebas locales pasan. node:path sí se resuelve en Webflow Cloud, lo que hace que el fallo parezca arbitrario, aunque sea una línea fija en el tiempo de ejecución.

Solución: Elimina por completo la dependencia del sistema de archivos. Un gestor de rutas que redirija a n8n puede mantener las plantillas en el código, mientras que los datos persistentes permanecen en n8n o en el CMS de Webflow.

Si el problema es un paquete de terceros, cámbialo por uno diseñado para entornos de ejecución web estándar y revisa sus importaciones antes de instalarlo. Luego, pruébalo en un despliegue real, ya que ni TypeScript ni el linter detectarán un entorno de ejecución al que le falte un módulo que el código intenta importar.

Qué puedes crear a continuación con n8n y Webflow

Una vez que los envíos pasan por una ruta bajo tu control, esa misma estructura permite ejecutar flujos programados en n8n que interactúan con el contenido del CMS y formularios que envían datos a varias herramientas. El CMS componible de Webflow cuenta con API REST, por lo que n8n puede utilizarlas en un flujo de trabajo, mientras que el gestor de rutas sigue siendo la puerta de entrada firmada y validada para cualquier acción del usuario.

Trato la ruta como el límite para los flujos de trabajo activados por los visitantes y dejo que n8n se encargue de las ramas posteriores.

Mantén la ruta para las partes que requieran tu propia validación o firma. Para conocer los detalles de conexión entre ambas plataformas, consulta la integración de Webflow y n8n.