Verifica sin backend
Un token de Caputchin no prueba nada hasta que algo lo confirma. Normalmente ese algo es tu propio backend, que llama a /siteverify y decide si fiarse de la petición. La verificación alojada mueve ese paso a Caputchin: tu formulario postea a un reenviador de Caputchin, Caputchin verifica el token, descarta lo que falla, y reenvía solo los envíos verificados a un destino que tú eliges.
Es la misma decisión de confianza que la comprobación de backend, corrida del lado de Caputchin en vez del tuyo. El punto es que no hay llamada a /siteverify que escribir ni secreto que guardar en un servidor, porque no hay servidor.
La verificación alojada es una función de pago, disponible en Alpha y superior.
Para quién es
La verificación alojada existe para el caso en que correr un backend solo para comprobar un token es más de lo que el proyecto necesita.
| Eres | Por qué encaja |
|---|---|
| Un sitio estático (Webflow, Framer, HTML plano en un CDN) | No hay servidor que reciba el formulario ni llame a /siteverify. |
| Un constructor no-code (Wix, Squarespace, Carrd) | No puedes añadir código de verificación en el servidor. |
| Un desarrollador en solitario o un equipo pequeño | Un formulario de contacto o registro no merece levantar y operar un backend. |
| Ya corres un backend, pero no para este formulario | Puedes apuntar un formulario al reenviador y dejar el resto de tu stack en paz. |
Si corres un backend y quieres verificar ahí, usa verifica en tu backend en su lugar. Los dos son alternativas, no capas.
Cómo funciona
El reenviador retiene el envío en memoria solo el instante que tarda en entregarlo. No hay almacenamiento entre el post y la entrega, y el campo caputchin-token se elimina antes de que el payload llegue a tu destino.
Destinos
Configuras uno o ambos por clave de sitio. Activar ambos es un patrón común: enviar a un webhook para procesar y enviarte una copia por correo.
| Destino | Qué recibes |
|---|---|
| Webhook | Un POST de JSON que lleva los campos de tu formulario más el metadato de verificación de Caputchin. |
| Correo | Un correo plano con los campos del formulario y un pie que indica que Caputchin verificó el envío. |
Las entregas no van firmadas. El secreto de la URL del reenviador es lo que autentica una llamada de webhook, así que mantén la URL fuera de repositorios públicos y de código del cliente. El tutorial de configuración muestra el payload exacto del webhook.
Qué se mantiene privado
La verificación alojada sigue la misma postura de cero-datos-de-visitante que el resto de Caputchin:
- Los envíos nunca se almacenan. Viven en la memoria del proceso durante el reenvío, luego desaparecen. Construye tu propio registro en el extremo del webhook si quieres uno.
- No se recoge ningún dato sobre quien envía. Ni IP, ni User-Agent, ni huella, ni rastreo.
- La telemetría es solo agregada. Caputchin cuenta éxitos y fallos de entrega para que puedas ver si tus destinos están sanos, nunca el contenido de ningún envío. Mira estadística.
Cómo se mantiene segura una URL suministrada por el cliente
Una URL que los servidores de Caputchin van a llamar es un riesgo clásico de Server-Side Request Forgery. El reenviador rechaza cualquier URL de webhook cuyo host sea una dirección privada, de loopback, link-local o de metadatos de nube, tanto al guardarla como de nuevo justo antes de cada entrega. Las categorías bloqueadas incluyen:
| Categoría | Ejemplos |
|---|---|
| Loopback y sin especificar | 127.0.0.1, 0.0.0.0, ::1 |
| Privadas (RFC 1918) | 10.x.x.x, 172.16.x.x hasta 172.31.x.x, 192.168.x.x |
| Link-local y metadatos de nube | 169.254.x.x, en particular el endpoint de metadatos 169.254.169.254 |
| Carrier-grade NAT | 100.64.x.x hasta 100.127.x.x |
| Multicast y reservadas | 224.x.x.x y superiores |
| Hostnames internos | localhost y cualquier host que acabe en .local, .localhost o .internal |
| IPv6 privadas | direcciones link-local (fe80::/10) y unique-local (fc00::/7) |
Las codificaciones que intentan disfrazar una dirección bloqueada también se atrapan: un host de entero decimal como http://2130706433/ o un host hex como http://0x7f000001/ (ambos significan 127.0.0.1) se rechazan. Solo se aceptan URLs http y https; cualquier otro esquema se rechaza. El reenviador también se niega a seguir redirects, así que un endpoint de webhook no puede rebotar la llamada a un objetivo interno. Una URL bloqueada aflora como un error genérico en vez de uno específico, así que no se puede usar para sondear una red. Tu webhook debe por tanto vivir en una URL https pública.
Qué se deja fuera a propósito
- Sin bandeja de envíos. No hay historial almacenado de envíos que navegar en el dashboard.
- Sin adaptadores de primera parte de Discord, Slack, Telegram o SMS. Solo webhook y correo. Un webhook puede repartir a cualquiera de esos de tu lado.
- Sin subidas de archivos. El reenviador acepta campos de texto; un envío que lleve un archivo se rechaza.
- Sin transformación del payload. Lo que el formulario postea es lo que tu destino recibe, más el metadato de verificación.
Véase también
- Configura la verificación alojada: un recorrido que la cablea primero a una bandeja de prueba.
- Estadísticas de verificación alojada: leer la salud de entrega.
- Verifica en tu backend: la alternativa cuando sí corres un servidor.