Una casilla de verificación desmarcada, que se vuelve a comprobar en el servidor y se confirma mediante un proceso de doble suscripción, proporciona a cada registro en el boletín un historial fechado del texto al que el suscriptor dio su consentimiento.
Un formulario de suscripción puede fallar en el consentimiento de dos formas: con una casilla marcada por defecto o con una sola casilla que agrupa los términos con los correos electrónicos de marketing. En ambos casos, cuando alguien pide pruebas, la única respuesta es que la dirección está en la lista.
En esta implementación, mantenemos el formulario en el Designer con la casilla desmarcada y añadimos un pequeño gestor de rutas en Webflow Cloud, en el mismo dominio. Este rechaza cualquier suscripción sin consentimiento y luego añade la dirección a Mailchimp como pendiente, de modo que un correo de confirmación completa la doble suscripción y la versión y fecha del consentimiento quedan guardadas en el suscriptor.
¿Qué necesitas para añadir una casilla de verificación de consentimiento RGPD a un formulario de Webflow?
Necesitas siete requisitos previos antes de empezar:
- Sitio de Webflow: Un sitio con un formulario que controles en el Designer, con un plan Premium o superior si la aplicación se aloja en tu dominio personalizado.
- Node.js y npm: Una versión de Node.js compatible con Webflow Cloud y npm, el único gestor de paquetes que admite Webflow Cloud.
- Next.js 15 o superior: La versión mínima indicada en la documentación de Webflow Cloud para integrar tu propia aplicación.
- Repositorio de código: Un repositorio que contenga la aplicación.
- Audiencia y clave API de Mailchimp: El ID de la audiencia, una clave API y tres campos de combinación de texto llamados
CONSENTV,CONSENTATyCONSENTPGpara el registro de consentimiento. Puedes usar otro proveedor si sustituyes la solicitud del paso 3 por su propia llamada de añadir o actualizar. - Texto de consentimiento: El texto final de la etiqueta acordado con tu responsable de privacidad, ya que la cadena de versión en el código debe coincidir con lo que lee el visitante.
- URL de la política de privacidad: Una página de política publicada para enlazar desde la etiqueta de la casilla de verificación, de modo que los visitantes puedan ver cómo se describe el uso de sus datos.
Si tu sitio aún muestra el nombre antiguo del plan CMS o Business, ambos se han integrado en el plan Premium.
Con todo esto listo, la implementación depende de una decisión que tomas en el Designer y que luego aplicas en el código: la casilla de verificación comienza desmarcada y lleva su propia etiqueta.
Cómo añadir una casilla de verificación de suscripción compatible con el RGPD en Webflow Cloud
La implementación consiste en un formulario del Designer cuya casilla de consentimiento comienza desmarcada, además de un gestor de rutas en Webflow Cloud que rechaza cualquier envío donde ese valor sea falso y almacena un registro de consentimiento versionado en el suscriptor de Mailchimp.
Lo que diferencia al gestor en Webflow Cloud es lo que omites, ya que la aplicación se ejecuta en Cloudflare Workers en lugar de Node. La ruta no lleva ninguna directiva de tiempo de ejecución y la configuración no establece ninguna ruta base. Los registros de consentimiento van a tu proveedor de correo electrónico en lugar de al sistema de archivos.
1. Añade la casilla de verificación de consentimiento al formulario en el Designer
Asigna al formulario un ID estable y tres campos con nombre antes de tocar nada de código. Abre el sitio en el Webflow Designer, selecciona el formulario de suscripción y establece su ID como newsletter-form. El campo de entrada de correo electrónico debe llamarse email.
Añade una casilla de verificación con el nombre marketing_consent, y asegúrate de que esté desmarcada por defecto; una casilla que se carga marcada solo registra el valor predeterminado de la página, por lo que el registro no podrá demostrar que el visitante la eligió.
Luego, añade otro campo de texto llamado hp_field, ocúltalo con una configuración de visualización y asígnale los atributos personalizados autocomplete="off" y tabindex="-1" para que los navegadores y los usuarios que usan teclado lo omitan. Ese campo oculto es un "honeypot", y el gestor de rutas (Route Handler) tratará como un bot a cualquiera que lo rellene. Evita nombres como company que el autorrelleno pueda completar, o podrías perder visitantes reales.
Redacción de la etiqueta de la casilla de verificación y el enlace de privacidad
Escribe la etiqueta como una frase independiente que explique a qué acepta el visitante, con qué frecuencia y dónde está la política de privacidad. Algo como: "Enviadme el boletín mensual de productos por correo electrónico.
Podéis daros de baja en cualquier momento; consultad nuestra política de privacidad". Mantengo el enlace de privacidad dentro de la propia etiqueta para que el propósito y el enlace a la política aparezcan en la misma línea que lee el visitante.
No mezcles esto con la aceptación de los términos de servicio. En un formulario exclusivo para boletines, el correo de marketing es lo único que se ofrece, por lo que el gestor de rutas rechazará cualquier envío que no tenga la casilla marcada. Si reutilizas el formulario para una descarga o un registro, separa la casilla de marketing para que el otro propósito funcione sin ella.
Haz coincidir los ID y los nombres de los campos exactamente para que el script y el gestor puedan encontrarlos. Al previsualizar la página, la casilla de verificación debería aparecer desmarcada con su etiqueta completa al lado, y el campo hp_field debería ser invisible.
2. Prepara la estructura de la aplicación Next.js con npm
Empieza con la estructura estándar de Next.js y nada más. Webflow Cloud es compatible con Next.js 15 o superior, y su documentación de personalización indica que no necesitas añadir un adaptador, una ruta base ni un modo de salida, así que comienza desde el proyecto predeterminado.
Usa npm en todo momento; la plataforma no admite pnpm ni yarn, así que mantén solo el archivo de bloqueo (lockfile) de npm en el repositorio.
Desde una terminal en la carpeta de tu proyecto, ejecuta:
npx create-next-app@15 consent-gate --typescript --app --eslint --no-tailwind --no-src-dir --import-alias "@/*"
cd consent-gate
npm run devEsto te dará una aplicación en funcionamiento con el App Router y un package-lock.json.
He dejado dos cosas fuera a propósito. No hay ningún export const runtime = 'edge' en ninguna parte, porque Webflow Cloud despliega Next.js a través del adaptador OpenNext Cloudflare, y ese adaptador no es compatible con el destino de tiempo de ejecución (runtime) edge de Next.js.
Y tampoco hay ningún basePath en next.config, porque la ruta de montaje la inyecta la plataforma durante la compilación. Resiste la tentación de añadir cualquiera de los dos, aunque la página actual de Webflow sobre cómo usar tu propia aplicación todavía sugiera la directiva edge.
Al final de este paso, npm run dev debería mostrar la página predeterminada de Next.js en localhost sin cambios en la configuración.
3. Escribe el gestor de rutas (Route Handler) de consentimiento
He creado el gestor para que solo llegue a tu proveedor un correo electrónico válido con consentimiento explícito y un honeypot vacío. Crea app/api/consent/route.ts. El gestor comprueba el origen de la solicitud frente a un valor permitido, analiza el cuerpo JSON, rechaza cualquier cosa donde marketing_consent no sea un valor true explícito o "on", y solo entonces reúne un registro de consentimiento y lo reenvía.
El registro incluye la cadena de versión del texto de la etiqueta y una marca de tiempo ISO, además de la página en la que estaba el visitante, lo que vincula a cada suscriptor con una versión del texto y un momento específico. Se almacena como campos de combinación en el perfil de Mailchimp del suscriptor, dentro de tu propia cuenta.
El gestor, al completo:
import { createHash } from "node:crypto";
import { NextResponse } from "next/server";
// Bump this whenever the checkbox label text changes, and keep the old wording on record.
const CONSENT_VERSION = "marketing-v1";
type Payload = {
email?: string;
marketing_consent?: string | boolean;
hp_field?: string; // honeypot, must stay empty
page?: string;
};
export async function POST(request: Request) {
const allowedOrigin = process.env.ALLOWED_ORIGIN;
const origin = request.headers.get("origin") ?? "";
if (!allowedOrigin || origin !== allowedOrigin) {
return NextResponse.json({ error: "Forbidden" }, { status: 403 });
}
let body: Payload;
try {
body = (await request.json()) as Payload;
} catch {
return NextResponse.json({ error: "Invalid JSON" }, { status: 400 });
}
if (body.hp_field) {
// Honeypot filled: treat as a bot and return a quiet success.
return NextResponse.json({ ok: true });
}
const email = (body.email ?? "").trim().toLowerCase();
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
return NextResponse.json(
{ error: "A valid email address is required" },
{ status: 400 }
);
}
const consented =
body.marketing_consent === true ||
body.marketing_consent === "on" ||
body.marketing_consent === "true";
if (!consented) {
return NextResponse.json(
{ error: "Marketing consent was not given" },
{ status: 400 }
);
}
const apiKey = process.env.MAILCHIMP_API_KEY;
const listId = process.env.MAILCHIMP_LIST_ID;
if (!apiKey || !listId) {
console.error("consent_route_misconfigured", {
hasKey: Boolean(apiKey),
hasList: Boolean(listId),
});
return NextResponse.json({ error: "Server misconfigured" }, { status: 500 });
}
// A Mailchimp key ends in its data center, for example "-us21".
const dataCenter = apiKey.split("-").pop();
// Mailchimp identifies a subscriber by the MD5 hash of the lowercase email.
const subscriberHash = createHash("md5").update(email).digest("hex");
const consentedAt = new Date().toISOString();
const mailchimpResponse = await fetch(
`https://${dataCenter}.api.mailchimp.com/3.0/lists/${listId}/members/${subscriberHash}`,
{
method: "PUT", // add or update, so a returning subscriber is not an error
headers: {
"Content-Type": "application/json",
Authorization: `Basic ${btoa(`anystring:${apiKey}`)}`,
},
body: JSON.stringify({
email_address: email,
status_if_new: "pending", // Mailchimp emails a confirmation link: double opt-in
merge_fields: {
CONSENTV: CONSENT_VERSION,
CONSENTAT: consentedAt,
CONSENTPG: (body.page ?? "").slice(0, 255),
},
}),
}
);
if (!mailchimpResponse.ok) {
console.error("mailchimp_error", mailchimpResponse.status, CONSENT_VERSION);
return NextResponse.json({ error: "Subscription failed" }, { status: 502 });
}
console.log("consent_recorded", CONSENT_VERSION, consentedAt);
return NextResponse.json({ ok: true, consent_version: CONSENT_VERSION });
}Ahora tienes una ruta que devuelve un 400 si la casilla no está marcada, un 403 si el origen es extranjero y un 502 si Mailchimp rechaza al suscriptor.
La comprobación explícita de configuración errónea facilita la identificación de una variable faltante al devolver una respuesta 500 clara. Guardamos el registro en el suscriptor en lugar de en un archivo porque el entorno de ejecución de Workers en el que se despliega Webflow Cloud no expone node:fs; node:path está disponible, pero el sistema de archivos no.
Los registros solo contienen la versión del consentimiento y la marca de tiempo, manteniendo las direcciones de correo electrónico fuera de ellos, ya que un correo electrónico en los registros de la plataforma es una copia adicional de datos personales que hay que gestionar. La comprobación de origen es una protección contra solicitudes entre sitios, no una autenticación, y rechaza toda solicitud cuando ALLOWED_ORIGIN no está configurado.
Formateo de credenciales de la API de Mailchimp y doble opt-in
La llamada a Mailchimp sigue la solicitud de añadir o actualizar que documenta la página de integración de Mailchimp de Webflow: autenticación básica HTTP con la clave API como contraseña, y el suscriptor identificado mediante el hash MD5 del correo electrónico en minúsculas, que node:crypto calcula tanto en next dev como en Webflow Cloud.
Como es un PUT, un suscriptor que regresa se actualiza en lugar de ser rechazado, y status_if_new: "pending" hace que Mailchimp envíe su correo de confirmación, por lo que la dirección solo se une a la lista cuando su propietario hace clic.
La comprobación de origen y el honeypot no son autenticación: un script puede falsificar la cabecera Origin y enviar cualquier dirección. El doble opt-in evita que una dirección falsificada entre en la lista, pero cada solicitud falsa sigue enviando un correo de confirmación a esa persona, así que añade un límite de velocidad antes del lanzamiento. La clave API permanece en el lado del servidor; nada secreto utiliza un prefijo NEXT_PUBLIC_.
Prueba del gestor de consentimiento localmente con variables de entorno
Crea un .env.local archivo en la raíz del proyecto para que la comprobación de origen pase localmente:
ALLOWED_ORIGIN=http://localhost:3000
MAILCHIMP_API_KEY=your-api-key-us21
MAILCHIMP_LIST_ID=your-audience-idCon esos tres valores establecidos, el gestor supera sus comprobaciones de origen y configuración en localhost, aunque la llamada a Mailchimp solo tiene éxito una vez que la clave y el ID de audiencia son reales.
Reinicia npm run dev, luego envía una solicitud sin marcar con una cabecera Origin coincidente:
curl -s -X POST http://localhost:3000/api/consent \
-H "Content-Type: application/json" \
-H "Origin: http://localhost:3000" \
-d '{"email":"test@example.com","marketing_consent":false}'La respuesta debería ser un 400 con el mensaje "No se dio el consentimiento de marketing". Un 403 significa que la cabecera Origin y ALLOWED_ORIGIN no coinciden.
4. Apunta el formulario del Diseñador al gestor de rutas
Intercepto el evento de envío del formulario y envío los campos como JSON a la ruta montada. El formulario del Diseñador y la aplicación de Webflow Cloud comparten dominio una vez que la aplicación está montada, por lo que una ruta relativa funciona y, como la solicitud es del mismo origen, no debería haber CORS que configurar. La ruta solo tiene que incluir la ruta de montaje, que es /signup para esta aplicación.
La plataforma no reescribe las solicitudes del lado del cliente, así que tú mismo escribes la ruta montada completa. Añade un elemento de texto dentro del formulario con el atributo data-consent-message para que el script tenga dónde escribir.
Añade un elemento de incrustación de código (Code Embed) a la página, debajo del formulario, y pega el script. Interceptar el envío tiene un coste: el formulario nunca llega al gestor propio de Webflow, por lo que Webflow ya no almacena el envío ni envía su correo electrónico de notificación.
Añadir el script del gestor de envíos a Webflow
Suelta esto en el elemento de incrustación de código:
<script>
document.addEventListener("DOMContentLoaded", function () {
var form = document.getElementById("newsletter-form");
if (!form) return;
form.addEventListener("submit", async function (event) {
event.preventDefault();
event.stopImmediatePropagation();
var data = new FormData(form);
var payload = {
email: data.get("email"),
marketing_consent: data.get("marketing_consent") === "on",
hp_field: data.get("hp_field") || "",
page: window.location.href
};
var response = await fetch("/signup/api/consent", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(payload)
});
var result = {};
try { result = await response.json(); } catch (e) { result = {}; }
var message = form.querySelector("[data-consent-message]");
if (!message) return;
if (response.ok) {
message.textContent = "You're subscribed. Check your inbox.";
form.reset();
} else {
message.textContent = result.error || "Something went wrong.";
}
}, true);
});
</script>El formulario ahora se envía a tu gestor en lugar de enviarse de forma nativa, y el visitante ve el mensaje de rechazo exacto del servidor cuando la casilla se deja sin marcar.
El oyente de fase de captura y stopImmediatePropagation están ahí para evitar que otros oyentes de envío en el formulario actúen también sobre el envío. Si la respuesta no es JSON, como una página 404, el mensaje vuelve a "Algo salió mal".
Este script reside en el Designer, fuera de la aplicación Next.js, por lo que codifica de forma rígida /signup. Si más adelante añades una página dentro de la propia aplicación que llame a la misma ruta, la función fetch de esa página debería leer la ruta de montaje desde NEXT_PUBLIC_BASE_PATH en lugar de codificarla, configurando esa variable con la ruta de montaje en el entorno de Webflow Cloud, ya que la plataforma no la crea por ti.
Verificación del envío de formularios y rutas de montaje
Por ahora, publica la página y envía el formulario una vez en el origen donde planeas realizar las pruebas. La página no debería recargarse y el panel de red debería mostrar una solicitud POST a /signup/api/consent que incluya la ruta de montaje.
Esa solicitud devuelve un error 404 hasta que montas la aplicación en Webflow Cloud, así que espera a realizar la prueba del formulario hasta que la aplicación esté montada. Una vez montada, una prueba devolverá un error 403 a menos que ALLOWED_ORIGIN coincida con el origen publicado, así que prueba las rutas de rechazo y éxito desde el dominio que hayas configurado.
5. Configura las variables de entorno, monta la aplicación y prueba ambas ramas
Envío el proyecto consent-gate a su repositorio antes de crear el proyecto y el entorno de Webflow Cloud para el sitio. Conecta ese repositorio y establece la ruta de montaje en /signup, siguiendo la documentación de configuración de Webflow Cloud enlazada en los requisitos previos. Si el montaje se realiza en tu dominio personalizado, el sitio requiere un plan Premium o superior.
En ese entorno, añade tres variables antes del primer despliegue: MAILCHIMP_API_KEY como secreto, MAILCHIMP_LIST_ID como texto plano, y ALLOWED_ORIGIN configurada con el origen de tu sitio.
Webflow Cloud pone a disposición tanto las variables secretas como las no secretas durante la compilación y en la aplicación desplegada en tiempo de ejecución, y oculta los secretos en los registros de compilación, por lo que la clave nunca aparece en la salida. Luego, despliega la aplicación y publica la página del Designer en el dominio personalizado.
Prueba de las respuestas de rechazo y éxito en producción
Con ALLOWED_ORIGIN configurado como el origen publicado en tu terminal, dos solicitudes permiten comprobar la ruta de rechazo y la de éxito:
# Unticked box: expect 400 and "Marketing consent was not given"
curl -s -X POST "$ALLOWED_ORIGIN/signup/api/consent" \
-H "Content-Type: application/json" \
-H "Origin: $ALLOWED_ORIGIN" \
-d "{\"email\":\"test@example.com\",\"marketing_consent\":false,\"page\":\"$ALLOWED_ORIGIN/\"}"
# Ticked box: expect 200 and the consent_version string
curl -s -X POST "$ALLOWED_ORIGIN/signup/api/consent" \
-H "Content-Type: application/json" \
-H "Origin: $ALLOWED_ORIGIN" \
-d "{\"email\":\"test@example.com\",\"marketing_consent\":true,\"page\":\"$ALLOWED_ORIGIN/\"}"Si ambas solicitudes devuelven las respuestas esperadas, la ruta desplegada coincide con el comportamiento local.
Revisa Mailchimp después de la segunda solicitud. La dirección debería aparecer como pendiente, con CONSENTV, CONSENTAT y CONSENTPG completados, y un correo de confirmación debería llegar a la bandeja de entrada de prueba; al hacer clic en él, el estado cambiará a suscrito.
Luego, envía el formulario real en un navegador con la casilla marcada y confirma que el registro llega correctamente. La solicitud /signup/api/consent en el panel de red debería devolver ahora un 400 o un 200 en lugar de un 404.
La ejecución se completa cuando un envío sin marcar desde la página en vivo muestra el mensaje de rechazo, uno marcado muestra el mensaje de éxito y Mailchimp muestra un suscriptor con marketing-v1 como versión de consentimiento.
¿Qué hace que una casilla de verificación de consentimiento GDPR falle en los formularios de Webflow?
Los pasos de solución de problemas a continuación cubren cuatro categorías: una directiva de tiempo de ejecución copiada de la documentación, una función fetch que no encuentra la ruta de montaje, una llamada al sistema de archivos que el entorno de ejecución de Workers no posee y un secreto configurado en el entorno incorrecto.
Utiliza estas cuatro categorías para aislar la causa.
El despliegue en Webflow Cloud falla para una ruta que funciona localmente
Causa: Webflow Cloud despliega Next.js a través del adaptador OpenNext de Cloudflare, y dicho adaptador no es compatible con el objetivo de tiempo de ejecución edge de Next.js. La confusión se debe a una colisión de nombres. Webflow Cloud se ejecuta en Cloudflare Workers, que es una plataforma edge, y la documentación lo describe de esa manera.
La directiva de Next.js export const runtime = 'edge' selecciona un objetivo de tiempo de ejecución independiente dentro de Next.js, y OpenNext no puede compilarlo. La propia página de Webflow para añadir tu propia aplicación sigue indicando que añadas la directiva a las rutas de API, por lo que un desarrollador que la añade está siguiendo la documentación fielmente y generando una compilación que OpenNext no puede completar.
Solución: Eliminé la línea de app/api/consent/route.ts y de cualquier otra ruta donde se hubiera añadido, y luego volví a desplegar. El manejador ya se ejecuta en Workers sin ninguna directiva; es la plataforma la que decide dónde se ejecuta el código, no la exportación.
El fallo aparece en el despliegue de Webflow Cloud. Deja una nota en el repositorio indicando que la directiva no es compatible, ya que la próxima persona que lea la página de documentación intentará volver a añadirla.
El formulario funciona en npm run dev, pero el sitio en vivo devuelve un error 404 para la ruta de consentimiento.
Causa: El manejador de rutas está desplegado y funciona correctamente, pero la petición fetch apunta a /api/consent sin la ruta de montaje, por lo que no está donde el navegador espera encontrarla. Localmente, la aplicación se encuentra en la raíz de localhost, así que la ruta directa funciona.
En Webflow Cloud, la aplicación se monta bajo una ruta como /signup, y las llamadas fetch del lado del cliente no se reescriben para incluirla; la documentación indica claramente que las llamadas fetch del lado del cliente deben incluir manualmente la ruta base.
Esto ocurre sobre todo cuando alguien copia el fetch de una prueba local o de una página de la aplicación que olvidó NEXT_PUBLIC_BASE_PATH. Comprobar primero la URL montada aísla el problema rápidamente, ya que la ruta funciona localmente.
Solución: En el embed del Designer, ajusto la URL a /signup/api/consent, haciendo que coincida exactamente con la ruta de montaje configurada en el entorno, incluyendo las mayúsculas y minúsculas.
Para cualquier fetch dentro de la propia aplicación Next.js, establece NEXT_PUBLIC_BASE_PATH en la ruta de montaje dentro del entorno de Webflow Cloud y construye la URL a partir de ahí, en lugar de leer basePath desde next.config, ya que la plataforma ya no espera que lo configures.
Tras volver a publicar la página del Designer, abre el panel de red del navegador al enviar el formulario; la URL de la solicitud debería incluir la ruta de montaje y devolver un 400 o 200 en lugar de un 404.
El despliegue en Webflow Cloud o la primera solicitud fallan en cuanto la ruta importa node:fs
Causa: La aplicación desplegada se ejecuta en Cloudflare Workers, no en Node, y node:fs no está disponible en la fecha de compatibilidad que Webflow Cloud tiene fijada actualmente.
No hay nada sintácticamente incorrecto en la importación, lo cual es lo que resulta confuso; node:path se importa bien, así que un desarrollador asume razonablemente que el resto del espacio de nombres node: sigue el mismo patrón. Pero no es así. Enviar el registro de consentimiento a través de HTTP encaja con este entorno de ejecución, mientras que un registro de consentimiento que añade líneas JSON a un archivo no funciona, independientemente de si el problema surge durante la compilación o la ejecución.
Solución: Mantengo el registro fuera del sistema de archivos local. El manejador en esta compilación lo almacena como campos de combinación en el suscriptor de Mailchimp, que es donde querrás tenerlo cuando alguien te pida una prueba.
Si cambias a un proveedor que no pueda almacenar campos personalizados, envía el registro mediante POST a un almacén externo a través de HTTP desde el mismo manejador, y mantén la línea console.log para que los registros de la plataforma incluyan la versión y la marca de tiempo.
Elimina la importación node:fs y cualquier llamada a fs.appendFile , luego vuelve a desplegar; el despliegue debería tener éxito y Mailchimp debería mostrar los campos de consentimiento en la siguiente solicitud marcada.
Mailchimp devuelve un error 401 desde la ruta desplegada, pero funciona localmente.
Causa: El manejador desplegado está enviando una clave API que Mailchimp rechaza. Las variables de entorno en Webflow Cloud se configuran por entorno, por lo que una clave que reside en tu archivo local .env.local no está presente en el entorno desplegado a menos que la hayas añadido allí con el mismo nombre. Los secretos se ocultan en los registros de compilación, por lo que el valor no aparece en el log.
Un error 401 significa que la clave llegó al manejador, pero Mailchimp la rechazó. Un nombre de variable faltante o mal escrito, o uno añadido a un entorno diferente, nunca llega tan lejos: la comprobación de configuración errónea del manejador devuelve un 500 "Servidor mal configurado" en su lugar.
Primero compruebo la distinción entre el 500 y el 401, porque me indica si el problema es el nombre o el valor. Un ALLOWED_ORIGIN faltante se muestra de forma diferente: el manejador devuelve un 403 para cada solicitud en lugar de un 401.
Solución: Abre el entorno desde el que se despliega realmente la aplicación y confirma que MAILCHIMP_API_KEY y MAILCHIMP_LIST_ID existen con esos nombres exactos. Las variables están disponibles tanto en la compilación como en la ejecución; vuelve a desplegar después de añadirlas.
Si los nombres coinciden y el error 401 persiste, la clave es incorrecta o pertenece a otra cuenta de Mailchimp; cámbiala, pégala de nuevo en el campo secreto y vuelve a ejecutar la solicitud curl marcada.
Un error 400 en lugar de un 401 suele significar que uno de los tres campos de combinación no existe en la audiencia. Un 200 con el consent_version en el cuerpo confirma la ruta de credenciales de principio a fin.
Qué más puedes crear con formularios de consentimiento y Webflow
Utilizo el mismo patrón de consentimiento versionado siempre que un visitante otorga permiso, incluso en registros a eventos y descargas restringidas donde la casilla de marketing es un campo independiente y opcional.
La misma aplicación de Webflow Cloud también podría servir para una página de centro de preferencias donde un suscriptor pueda ver a qué versión dio su consentimiento y retirarlo. El patrón de interceptación de envío también valida números de teléfono en un formulario de Webflow antes de que un cliente potencial llegue a tus sistemas.
Los especialistas en marketing siguen editando y publicando el formulario en el Diseñador, y cualquier cambio en la redacción de la etiqueta se envía junto con una CONSENT_VERSION actualización en el controlador de rutas para que los registros nunca apunten al texto incorrecto.
Para una personalización más profunda de lo que permite un formulario nativo, la documentación para desarrolladores de Webflow cubre los entornos de Webflow Cloud y lo que el tiempo de ejecución de Workers ofrece y lo que no.
Preguntas frecuentes
¿Debo marcar la casilla de consentimiento como obligatoria en el Diseñador?
En este formulario exclusivo para boletines, sí: el navegador marca la casilla vacía antes de enviar cualquier solicitud, y la ruta sigue rechazando un envío sin marcar. Nunca la hagas obligatoria en un formulario que haga algo más, como una descarga o un registro, porque el consentimiento condicionado no se otorga libremente.
¿Necesito también una doble confirmación (double opt-in)?
Esta versión ya la utiliza: status_if_new: "pending" hace que Mailchimp envíe un enlace de confirmación por correo electrónico. La configuración de doble confirmación de Mailchimp solo cubre sus propios formularios de registro, por lo que un registro vía API necesita ese campo. El RGPD no exige la doble confirmación, pero en algunos países, como Alemania, es la forma habitual de demostrar el consentimiento.
¿Dónde guardo el texto para cada CONSENT_VERSION?
Guardo la redacción de cada etiqueta junto con su cadena de versión, ya sea en el repositorio o en una colección de CMS de Webflow, para que la versión de un suscriptor pueda coincidir con la frase exacta que vio. Cuando la etiqueta cambie, actualiza CONSENT_VERSION en el controlador de rutas y publica el cambio de etiqueta al mismo tiempo. Nunca edites una entrada antigua.
¿Cómo se relaciona una baja de suscripción con el registro de consentimiento?
Trato los campos de consentimiento como un historial, mientras que la baja del proveedor de correo electrónico gestiona la retirada, por lo que el visitante abandona la lista sin tocar el controlador de rutas. Los campos del suscriptor muestran cuándo y bajo qué versión se inscribieron. Cuánto tiempo conservas ese historial tras una baja es una decisión de retención de quien se encargue de la privacidad en tu equipo.
