Saltar al contenido

Automatización · 7 min de lectura

Conectar CRM, formularios y herramientas mediante API: qué hace falta y dónde falla

Qué significa conectar un formulario con el CRM y el resto de herramientas por API, qué tiene que tener cada programa, los errores que se repiten (duplicados, reintentos, campos que cambian) y qué pide la ley cuando viajan datos de personas.

Por Equipo Zubicode

¿Un proyecto parecido? Hablemos
Tres fichas de cristal (un formulario, un contacto y un engranaje) unidas por líneas de luz a un cubo de cristal con anillo de neón

Conectar un CRM, los formularios de la web y el resto de herramientas por API significa que cada programa entrega los datos al siguiente sin que nadie los copie a mano: el formulario crea el contacto en el CRM, el CRM avisa a facturación, facturación actualiza la hoja de seguimiento. Para que funcione hacen falta tres cosas: que cada herramienta tenga una forma de conectarse (una API o, como mínimo, webhooks), un sitio donde viva la lógica que las une y reglas claras para los errores y para los datos de personas.

Lo demás son detalles, y los detalles deciden si la integración aguanta un año o se rompe el primer mes.

Qué es conectar herramientas por API y qué no lo es

Una API es la puerta que un programa abre para que otros programas lean o escriban en él sin pasar por su pantalla. Conectar por API es usar esa puerta: la web envía el formulario al CRM y el CRM responde con el identificador del contacto creado.

No es conectar por API:

  • Exportar e importar ficheros CSV cada noche: la información llega con horas de retraso y nadie sabe qué fila falló.
  • Un robot que rellena la pantalla del programa como si fuera una persona: se rompe con cada cambio de diseño.
  • Un formulario que manda un correo que alguien copia al CRM: el caso más común en pymes y el que más datos pierde.

Si una herramienta no tiene API ni webhooks, queda decidir entre cambiarla o aceptar un puente frágil. Mejor saberlo antes de presupuestar.

Las tres piezas: origen, destino y lo que hay en medio

Casi todas las integraciones de una pyme tienen la misma forma.

  • El origen es donde nace el dato: un formulario de la web, un pedido de la tienda, un correo con un adjunto.
  • El destino es donde tiene que acabar: el CRM, el programa de facturación, el ERP, una hoja de cálculo compartida.
  • Lo que hay en medio es la lógica: comprobar que el correo del contacto es válido, buscar si ya existe, decidir a qué comercial se asigna, avisar por chat si el pedido supera un importe.

Esa lógica puede vivir en una plataforma de integración (n8n, por ejemplo) o en un programa propio. Lo que no puede es vivir en ningún sitio: si cada herramienta llama directamente a la siguiente, el día que cambies una tienes que tocar todas.

Webhook o consulta periódica

Hay dos maneras de enterarse de que ha pasado algo. Con un webhook, la herramienta de origen avisa en el momento: «se ha enviado un formulario», con los datos dentro. Con una consulta periódica, tu lógica pregunta cada cierto tiempo si hay novedades.

El webhook es inmediato, pero si tu sistema está caído cuando llega el aviso, se pierde salvo que la herramienta lo reintente. La consulta periódica llega con retraso y no pierde nada. Para un formulario de contacto, webhook con reintento; para sincronizar un catálogo, consulta periódica.

Qué pedir a cada herramienta antes de conectarla

Antes de aceptar una integración, miramos la documentación de cada programa y buscamos cinco cosas. Si falta alguna, el presupuesto cambia.

Qué miramos Por qué importa
API documentada y vigente Sin ella, cada llamada es prueba y error, y la versión puede retirarse sin aviso
Webhooks o un punto de consulta de cambios Define si la integración será inmediata o con retraso
Cómo se autentica (clave, OAuth, token con caducidad) Decide dónde se guarda el secreto y cada cuánto hay que renovarlo
Límites de llamadas por minuto o por día Un pico de pedidos puede topar con el límite y dejar datos sin pasar
Un identificador único por registro Sin él no se puede saber si un contacto ya existe, y aparecen duplicados

El último punto es el que más se pasa por alto: si el CRM identifica por correo y el formulario lo admite con mayúsculas o espacios, el mismo cliente acaba tres veces.

Los errores que se repiten en una integración por API

Las integraciones no fallan por lo que hacen cuando todo va bien. Fallan en los bordes.

  • Duplicados por reintento. La red falla a mitad de una llamada, tu lógica reintenta y el CRM crea el contacto dos veces. La solución tiene nombre: idempotencia. Stripe, por ejemplo, documenta una cabecera Idempotency-Key con la que una petición repetida devuelve la respuesta guardada de la primera en vez de ejecutarse otra vez; recomienda claves aleatorias con suficiente entropía y pide no usar datos sensibles (un correo, por ejemplo) como clave. Si la herramienta de destino no ofrece nada parecido, la lógica intermedia tiene que buscar antes de crear.
  • Campos que cambian. Alguien añade un campo obligatorio en el CRM y desde ese día todas las llamadas fallan. Un registro de errores que avise en el momento, no un lunes al mirar la hoja, es la diferencia entre perder una tarde y perder un mes de contactos.
  • Límites alcanzados. Una campaña funciona, entran cientos de formularios en una hora y la API del CRM responde «demasiadas peticiones». Sin una cola que espere y reintente, esos contactos no llegan.
  • Secretos a la vista. La clave de la API pegada en un formulario de la web o en una hoja compartida. Quien la vea tiene tu CRM entero.

Ninguno de estos errores se ve en la demostración. Todos aparecen en producción.

Seguridad y datos personales cuando conectas herramientas

Una integración abre puertas entre programas, y hay que saber quién entra por ellas. El OWASP API Security Top 10 de 2023 pone en los dos primeros puestos la autorización rota a nivel de objeto (API1) y la autenticación rota (API2): en lenguaje llano, que una llamada pueda leer registros que no le corresponden o que entre sin acreditarse bien. Lo que pedimos en toda conexión: una credencial propia por integración, con los permisos justos (crear contactos, no borrar la base de datos) y que se pueda revocar sin tocar las demás.

Y la parte legal: un formulario de contacto lleva datos de personas. Si la lógica intermedia corre en una plataforma de terceros, esa plataforma trata esos datos por cuenta de tu empresa: es un encargado del tratamiento, y el Reglamento (UE) 2016/679 exige en su artículo 28 que esa relación se rija por un contrato u otro acto jurídico con un contenido mínimo. En la práctica: antes de conectar el formulario a una herramienta en la nube, se comprueba que ofrece ese contrato y dónde guarda los datos, y se anota en el registro de actividades.

Plataforma de integración o código propio

Una plataforma de integración como n8n trae conectores para los programas más comunes, un editor visual y un registro de cada ejecución; es la opción rápida cuando las herramientas son conocidas y la lógica es corta, y puede instalarse en tu propio servidor. El código propio tiene sentido cuando la lógica es larga o el destino es un programa hecho a medida: cuesta más al principio, pero no depende de que la plataforma mantenga el conector que necesitas. Lo habitual es combinarlas: la plataforma para los flujos sencillos y un servicio propio para el tramo que ninguna plataforma resuelve bien.

Preguntas frecuentes sobre conectar un CRM por API

¿Mi CRM tiene API?

Los más extendidos la tienen, pero no todos los planes la incluyen y algunos la limitan a lectura. Se mira en la documentación del proveedor, no en la ficha comercial, con el plan que tienes contratado.

¿Qué pasa si la integración se cae a las tres de la mañana?

Depende de lo que se haya previsto. Con webhooks con reintento, una cola y un aviso de error, los datos esperan y entran cuando el sistema vuelve. Sin eso, se pierden sin que nadie lo sepa hasta que un cliente pregunta por qué no le han llamado.

El siguiente paso

Si tienes un formulario, un CRM y dos o tres herramientas que hoy se comunican a base de copiar y pegar, cuéntanos cuáles son en contacto: con los nombres de los programas podemos decirte si se pueden conectar por API y por dónde empezaríamos. Cómo trabajamos estos flujos está en la página de automatización de procesos.

Fuentes

¿Te ayudamos a llevarlo a tu negocio?

Cuéntanos qué quieres resolver y te diremos qué pieza lo hace y por qué, sin compromiso.

Cuéntanos tu proyecto

En resumen

Qué significa conectar un formulario con el CRM y el resto de herramientas por API, qué tiene que tener cada programa, los errores que se repiten (duplicados, reintentos, campos que cambian) y qué pide la ley cuando viajan datos de personas.

  • API
  • CRM
  • formularios
  • integración de sistemas
  • automatización

Servicio relacionado

Automatización de procesos

Flujos que hacen solos el trabajo repetido: pedidos, facturas, avisos e informes, sin copiar datos a mano.

Ver el servicio

Para seguir leyendo

Automatizar un proceso empresarial: metodología paso a paso

Automatización · 7 min de lectura

Cómo trabajamos

Un proceso claro, sin sorpresas

  1. Descubrimos Nos cuentas el problema. Preguntamos por tu negocio, no por la tecnología.
  2. Diseñamos Te proponemos por escrito qué construir, qué esperar y cuánto cuesta.
  3. Desarrollamos Construimos por entregas que pruebas en tu móvil o en tu navegador.
  4. Publicamos Subimos la app a las tiendas o la web a su servidor, y seguimos contigo.
Ver el proceso

¿Una duda sobre tu caso?

Escríbenos y te decimos si lo que tienes en mente pide una app, una automatización o un programa a medida.

Hablemos

Seguir leyendo

Más guías del blog

Ver todos los artículos