> For the complete documentation index, see [llms.txt](https://docs.dapta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dapta.ai/dapta-docs-es/dforms/connect/spam-protection.md). # Protección contra spam (captcha) Activa una verificación humana antes del envío final de un formulario para frenar los envíos de bots. Elige el modo Automático o Estricto, mira qué ve quien responde y cómo se comportan las respuestas La protección contra spam agrega una verificación humana, de Cloudflare Turnstile, justo antes del envío final de un formulario. Frena a los bots que llenan tu formulario y saturan tus webhooks y HubSpot con contactos basura. Viene apagada, y la activas formulario por formulario. *** **Paso 1:** Abre el formulario en el editor, haz clic en **Conectar** en la barra superior y baja hasta la última sección, **Protección contra spam (captcha)**.
La sección Protección contra spam (captcha) al final de la pestaña Conectar, con el interruptor apagado

La última sección de la pestaña Conectar. La mayoría de los formularios nunca la necesita.

*** **Paso 2:** Activa **Verificar que quien responde es una persona antes del envío final**. Debajo del interruptor aparecen dos modos, con **Automático: solo quien parezca sospechoso ve una verificación (recomendado)** seleccionado.
La sección Protección contra spam con el interruptor encendido, el modo Automático seleccionado y las notas sobre respuestas parciales y publicación

Activada, en modo Automático. Las notas debajo de los modos dicen qué cambia y cuándo se aplica.

La sección ahora dice *Las respuestas parciales se siguen guardando en Envíos, pero no se envían a webhooks ni a HubSpot mientras la protección esté activa.* Las secciones siguientes explican las dos mitades de esa frase. *** **Paso 3:** Elige el modo.
La sección Protección contra spam con el modo Estricto seleccionado y su texto de ayuda

Estricto muestra la verificación a todos y agrega dos controles propios.

| Modo | Qué ve quien responde | Controles extra | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Automático: solo quien parezca sospechoso ve una verificación (recomendado)** | Nada, en la mayoría de los casos. Solo aparece una casilla cuando Cloudflare considera sospechosa la visita. | Ninguno. | | **Estricto: todos ven la verificación antes de enviar, con controles extra** | La verificación, siempre, antes de enviar las respuestas. | Un campo oculto al que ninguna persona puede llegar, y un tiempo mínimo de llenado: se rechaza un formulario completado menos de 2 segundos después de que la persona lo abrió por primera vez. | El propio producto aconseja sobre **Estricto**: *Úsalo si sigue entrando spam. Agrega un paso visible para todos.* *** **Paso 4:** Haz clic en **Publicar**. El ajuste viaja con tu borrador, igual que los IDs de seguimiento, y la sección lo dice: *Se guarda con tu borrador: haz clic en Publicar para aplicarla al formulario público.* Hasta que publiques, el formulario en vivo mantiene su ajuste anterior. > **💡 Tip:** La vista previa del editor nunca muestra la verificación. Para verla, abre el formulario publicado en otra pestaña. Si apagas el interruptor y lo vuelves a encender, el modo vuelve a **Automático**. *** ## Qué ve quien responde La verificación se ubica justo encima del botón que termina el formulario, así que la página nunca cambia por ella: | Diseño | Dónde se hace la verificación | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Una página** | Justo encima de **Enviar**. | | **Diapositivas** | Justo encima del botón del último paso, o de la última pantalla cuando varias preguntas comparten pantalla. Mira [Varias preguntas en una pantalla](/dapta-docs-es/dforms/builder/screens.md). | | Un final sin botón | En la pantalla de envío. Eso incluye una opción única o un desplegable que avanza solo, y una pantalla de revelación o un agendador como último paso. | La verificación se carga cuando la persona empieza a responder y el botón está en pantalla, y trabaja mientras termina, así que casi siempre las respuestas salen sin esperar. Mientras termina, el botón dice **Enviando…**. Sigue el idioma del formulario y su tema claro u oscuro.
Un formulario publicado de una página con la casilla de verificación de Cloudflare justo encima del botón Enviar

En modo Estricto todos ven la verificación encima de Enviar. En modo Automático solo aparece en una visita sospechosa.

Si algo sale mal, las respuestas siguen escritas y el mensaje aparece junto al botón: | Mensaje | Cuándo aparece | | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | *No pudimos verificar que eres una persona. Inténtalo de nuevo.* | La verificación no pasó. El formulario ya reintentó una vez por su cuenta antes de mostrarlo. | | *No pudimos completar la verificación de seguridad. Tus respuestas quedaron guardadas. Inténtalo de nuevo.* | La verificación no pudo hacerse: no se pudo contactar a Cloudflare, o la verificación no se cargó en el navegador. Mira [Cuando la verificación no puede hacerse](#cuando-la-verificacion-no-puede-hacerse). | | *Este formulario ahora verifica que eres una persona. Recarga la página y vuelve a enviar tus respuestas.* | La página se abrió antes de que activaras la protección. | En la pantalla de envío, una verificación que necesita un clic muestra *Confirma que eres una persona para enviar tus respuestas.*, y una que falló ofrece **Reintentar**. *** ## Qué cambia para tus integraciones Mientras la protección está activa, una sola regla aplica a cada destino: * Una respuesta **parcial** se sigue guardando y sigue apareciendo en [Respuestas](/dapta-docs-es/dforms/results/submissions.md), pero no se envía a los webhooks ni a HubSpot. * Una respuesta **completa** primero se verifica, y luego se guarda y se entrega como siempre. Los [correos de respuesta](/dapta-docs-es/dforms/connect/emails.md) no cambian: ya se enviaban solo en respuestas completadas. Tus ajustes quedan tal como los guardaste. Un webhook mantiene marcada la casilla **Respuestas parciales**, y al apagar la protección vuelven las entregas parciales. Mientras tanto, el panel marca lo que está en pausa: | Dónde | Qué muestra | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Tarjeta del webhook, **Disparar en** | **En pausa mientras la protección contra spam está activa**, junto a **Respuestas parciales**. Un webhook que solo escucha parciales además avisa *Este webhook no se va a disparar: solo escucha respuestas parciales, que están en pausa mientras la protección contra spam está activa.* | | Tarjeta de HubSpot, **Cómo funciona la sincronización** | *La protección contra spam está activa: los contactos se crean o actualizan cuando alguien completa el formulario, no con respuestas parciales.* | | Página **Integraciones**, tabla **Webhooks**, **Eventos** | **Completas (parciales en pausa)** o **Respuestas parciales (en pausa)**. | | Pestaña **Construir**, la ventana de información del **Punto de envío parcial** | *Con la protección activa, las parciales se guardan pero no se envían a integraciones.* |
La fila Disparar en de la tarjeta del webhook con la marca En pausa mientras la protección contra spam está activa junto a Respuestas parciales

La casilla de parciales sigue marcada, pero no se envía nada parcial mientras la protección está activa.

El recuadro Cómo funciona la sincronización de la tarjeta de HubSpot con la nota de la protección contra spam

En la tarjeta de HubSpot, la nota aparece junto a la regla que cambia.

> **⚠️ Nota:** Las marcas de la pestaña **Conectar** siguen el interruptor de tu borrador, así que aparecen apenas lo activas. Las entregas cambian solo cuando haces clic en **Publicar**. La tabla **Webhooks** de la página **Integraciones** siempre muestra el formulario publicado. **Enviar prueba** en la tarjeta del webhook sigue mandando su ejemplo mientras las parciales están en pausa, así que puedes seguir probando tu endpoint. *** ## Reservas del agendador Una reserva hecha desde un [paso de agendador](/dapta-docs-es/dforms/connect/scheduler-and-calendly.md) también queda cubierta. Con la protección activa, la [sincronización de reservas](/dapta-docs-es/dforms/connect/hubspot/booking-sync.md) escribe en HubSpot solo si se cumple una de estas condiciones: * Calendly confirma a la persona invitada a través de tu conexión de Calendly. * La persona ya completó el formulario, y por lo tanto pasó la verificación. Si no, la reserva queda registrada pero la sincronización se omite. El **Historial de HubSpot** muestra una fila **Omitida** con el motivo. *** ## Cuando la verificación no puede hacerse A veces la verificación no puede hacerse: Cloudflare no responde por un momento, una extensión del navegador la bloquea o el navegador no es compatible. No se pierde nada: 1. Las respuestas se guardan como una respuesta parcial. Como toda parcial mientras la protección está activa, no se entrega. 2. La persona lee *No pudimos completar la verificación de seguridad. Tus respuestas quedaron guardadas. Inténtalo de nuevo.* 3. Cuando lo intenta de nuevo y la verificación pasa, esa misma respuesta pasa a completa y se entrega. *** ## Envíos que no pasan por el formulario La verificación la comprueba la API de dForms, no solo el navegador. Un script que envía directo al endpoint público de respuestas sin una verificación válida es rechazado y no se guarda nada. Los códigos de error están en [API pública y límites de tasa](/dapta-docs-es/dforms/developers/public-api.md). *** ## Privacidad * El script de Cloudflare se carga solo en los formularios con la protección activa, y solo cuando la persona empieza a responder. Quien solo mira el formulario no le envía nada a Cloudflare. * Para comprobar una verificación, dForms le envía a Cloudflare el token de la verificación y, cuando es una dirección pública, la dirección IP de la persona. Ninguno de los dos se guarda con la respuesta. * Los intentos rechazados se registran sin ninguna respuesta y no cuentan en [Analíticas](/dapta-docs-es/dforms/results/analytics.md). Más sobre qué se guarda y qué no en [Seguridad y privacidad](/dapta-docs-es/dforms/security-and-privacy.md). > **💡 Tip:** ¿Tienes tu propia instalación de dForms? La protección contra spam necesita claves de Cloudflare Turnstile en tu despliegue. Mira [Flags de funcionalidad y entorno](/dapta-docs-es/dforms/developers/environment-flags.md). ## Qué sigue * [Webhooks](/dapta-docs-es/dforms/connect/webhooks.md): los disparadores parcial y completo. * [Cómo funciona la sincronización y solución de problemas](/dapta-docs-es/dforms/connect/hubspot/how-sync-works.md): cuándo se crea o actualiza un contacto. * [Respuestas parciales (punto de captura)](/dapta-docs-es/dforms/builder/partial-submissions.md): dónde va el punto de envío parcial. * [Entrega, reintentos e historial](/dapta-docs-es/dforms/connect/delivery-and-retries.md): qué pasa después de una respuesta. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.dapta.ai/dapta-docs-es/dforms/connect/spam-protection.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.