Durante meses, cada persona que nos escribía desde flouvia.com viajaba a un escenario de Make. Funcionaba, hasta que lo auditamos: la URL del webhook estaba visible en el navegador, no había validación del lado del servidor y, si Make fallaba, el mensaje simplemente desaparecía. Para una firma que construye software a la medida, era el ejemplo de lo que les decimos a nuestros clientes que no hagan.
Lo que estaba mal
- El secreto no era secreto. El formulario hacía fetch directo a la URL de Make. Cualquiera que abriera las herramientas del navegador podía copiarla y llenar nuestro escenario de basura.
- Nada validaba en el servidor. La única validación era la del propio formulario, que cualquier script se salta.
- Los fallos eran silenciosos. Si el escenario tenía un error o se quedaba sin operaciones, el lead no quedaba guardado en ningún lado.
- La lógica vivía fuera del repositorio. Cambiar un campo del formulario obligaba a acordarse de actualizar el escenario a mano.
El flujo nuevo, paso a paso
Lo reescribimos como cualquier otra parte del producto: en el mismo repositorio, tipado, probado y desplegado con el sitio.
- El navegador envía a nuestra propia API (/api/contact), nunca a un tercero. Cada envío lleva una clave única generada en el navegador.
- La API filtra antes de tocar nada: solo acepta peticiones de nuestro propio dominio, limita los envíos por IP y valida cada campo contra un esquema. Las opciones del formulario salen del mismo archivo que usa la validación, así que no pueden desalinearse.
- Los bots se descartan en silencio. Un campo oculto que una persona nunca llena y un tiempo mínimo de llenado separan a la gente de los scripts. El bot recibe una respuesta normal, para que no aprenda a esquivar el filtro.
- Primero se guarda, después se avisa. El lead se escribe en Postgres antes de enviar cualquier correo. Si el correo falla, el registro queda con el error anotado y se puede reintentar desde nuestra consola interna.
- Dos correos, un solo proveedor: un aviso al equipo, que al responderlo le escribe directo a quien nos contactó, y una confirmación para la persona en su idioma. Todo pasa por un único módulo de correo sobre Resend.
La clave que hace todo seguro: idempotencia de punta a punta
La parte menos visible es la más importante. La clave que genera el navegador viaja hasta la base de datos, donde es única, y de ahí a cada correo, que lleva su propia clave estable. El resultado:
- Si la red falla y la persona vuelve a enviar, no se crea un lead duplicado.
- Si reintentamos un aviso que en realidad sí había salido, el proveedor de correo lo reconoce y no lo manda dos veces.
- Si la persona cambia algo en el formulario, se genera una clave nueva: es otro envío.
Lo que ganamos
| Antes (Make) | Ahora (código propio) | |
|---|---|---|
| Dónde vive el lead | En el escenario, si corrió | En nuestra base de datos, siempre |
| Si algo falla | Se pierde sin aviso | Queda guardado con el error y se reintenta |
| Spam | Sin filtro | Origen, límite por IP, campo trampa y tiempo mínimo |
| Cambiar el formulario | Código y escenario por separado | Un solo archivo de opciones |
| Pruebas | Manuales | Automáticas en cada despliegue |
¿Entonces Make está mal?
No. Make es una buena herramienta para conectar aplicaciones que ya se hablan y para validar una idea rápido. El problema aparece cuando un flujo se vuelve crítico para el negocio: ahí necesitas que viva donde vive tu producto, con las mismas reglas de seguridad, las mismas pruebas y el mismo historial. Un lead que se pierde no es un error técnico; es una venta que nunca supiste que existía.
Si una automatización es crítica para tu operación, merece el mismo cuidado que el resto de tu software.
Es el mismo criterio que aplicamos en Cord y en los sistemas que construimos para nuestros clientes: lo que mueve dinero o clientes vive en código propio, auditado y con su propia red de seguridad.