Webhooks seguros: protege los datos que llegan al CRM
Un formulario puede crear un cliente potencial en el CRM en segundos. Antes de automatizar ese paso, conviene comprobar quién puede enviar datos a la conexión y qué operaciones puede provocar. Diseñar webhooks seguros para el CRM consiste en controlar esa entrada, incluso cuando el mensaje parece correcto.
Un webhook es un aviso que una aplicación envía a otra cuando ocurre un evento. Si ya tienes un flujo de formularios y seguimiento comercial con n8n, esta guía te ayuda a revisar su puerta de entrada. El objetivo es acordar pruebas con quien mantiene la integración.
Separa el formulario público de la conexión privada
El visitante rellena el formulario; el servidor recibe la solicitud; después, ese servidor conecta con el CRM o con la automatización. La clave de acceso al CRM debe permanecer en el servidor. Incluirla en JavaScript, en un campo oculto o en la dirección de un enlace la expone a quien recibe la página.
Un formulario público sigue necesitando controles contra spam y abuso. Autenticar el envío entre servidores no demuestra que el teléfono pertenezca al visitante ni que su consulta sea verdadera. Por eso, una solicitud nueva puede entrar como pendiente de revisión antes de desencadenar otras acciones comerciales.
Verifica el origen antes de modificar el CRM
Usa el mecanismo documentado por el proveedor. Por ejemplo, GitHub permite verificar la firma del mensaje mediante un secreto, antes de procesarlo. La comprobación detecta cambios en el contenido firmado; requiere conservar el cuerpo original de la petición.
Para el proyecto, pide una demostración sencilla: una entrega válida debe continuar y otra con firma incorrecta debe detenerse antes de crear registros. Si la herramienta solo admite una credencial compartida, documenta esa limitación; no presentes una contraseña estática como si firmara cada mensaje.
Una firma válida tampoco significa «primera entrega»
Un mensaje auténtico puede recibirse de nuevo. Stripe combina su firma con una marca temporal firmada para detectar entregas demasiado antiguas. Cada proveedor define su protocolo; no copies una tolerancia temporal sin revisar su documentación.
Además, asigna a cada evento una referencia estable y controla si su operación ya se completó. Son controles complementarios. El plazo de conservación de esas referencias debe cubrir los reenvíos previstos. Si necesitas diseñar la recuperación, consulta la guía sobre reintentos sin duplicar operaciones.
Decide qué datos pueden cambiar
OWASP recomienda validar en el servidor y definir campos, formatos y tamaños aceptados. Validar un dato y autorizar una operación son comprobaciones distintas.
Ejemplo hipotético: una empresa recibe solicitudes de mantenimiento. Su integración admite nombre, empresa, contacto y descripción. El estado inicial es «pendiente» y el responsable se calcula con reglas internas. Si llega también un campo «descuento aprobado», el flujo no lo copia al CRM: ese dato requiere otro proceso y otra autorización.
Prepara un mapa de campos con tres columnas: dato recibido, destino y regla aplicable. Evita copiar todo el contenido recibido directamente al registro. Comprueba también los permisos reales de la cuenta técnica: crear un lead no debería conceder automáticamente permiso para borrar clientes o modificar facturas. Si la API no ofrece permisos suficientemente precisos, habrá que valorar una capa intermedia o reducir el alcance.
Cinco pruebas que puedes pedir antes de activar el flujo
- Origen no válido: el CRM no recibe ninguna operación y queda un motivo de rechazo identificable.
- Contenido alterado: la verificación falla aunque el mensaje conserve una firma anterior.
- Mismo evento dos veces: se mantiene un solo resultado, también con entregas simultáneas.
- Campo no autorizado: una solicitud no puede cambiar descuentos, propietarios o estados reservados.
- Cambio de credencial: la nueva conexión funciona y la credencial retirada deja de aceptarse según el procedimiento acordado.
Realiza estas pruebas en un entorno autorizado con datos ficticios. Conserva fecha, identificador de prueba, resultado esperado y resultado observado. Para investigar fallos, prioriza referencias y motivos; evita almacenar claves o mensajes completos de clientes en los registros de diagnóstico.
Qué pedir en la entrega de la integración
Solicita un esquema del recorrido, el mapa de campos, las pruebas realizadas y el nombre del responsable de mantenimiento. Aclara cómo se pausa la entrada si aparece un problema y cómo se revisan las solicitudes pendientes antes de reanudarla.
En Serboweb estudiamos integraciones entre aplicaciones según las interfaces y permisos disponibles. Cuéntanos qué formulario utilizas, qué CRM recibe los datos y qué acciones debe permitir la conexión. Con esa información podemos valorar el alcance y las pruebas necesarias, sin pedirte claves en el formulario de contacto.