Integrar dos sistemas: cuándo necesitas una API

Casi todas las empresas con las que hablamos tienen la misma escena montada, aunque la cuenten con otras palabras. Hay un sistema donde entran los clientes y otro donde se factura. Entre los dos hay una persona que exporta un CSV los viernes, o un becario que copia números a mano, o una automatización que alguien montó hace tres años y que nadie se atreve a tocar porque funciona a medias y da miedo.

Lo que sigue es siempre igual: los datos se desincronizan, alguien factura sobre información vieja, y cuando pides un informe consolidado la respuesta es “depende de qué sistema mires”. Integrar esos dos sistemas es la solución obvia. Lo que no es obvio es cuándo basta con un conector de catálogo y cuándo hace falta construir una API a medida, que es una decisión de varios miles de euros y que casi siempre se toma con la información equivocada.

Qué significa integrar de verdad dos sistemas

La versión ingenua de una integración es “que el sistema A mande los datos al sistema B”. Con esa definición, cualquier conector de marketplace parece suficiente y cualquier presupuesto de desarrollo parece caro.

La versión real incluye tres preguntas que el conector no responde por ti. La primera es quién manda sobre cada campo: si el teléfono del cliente cambia en el CRM y también en el ERP, ¿cuál gana? La segunda es qué pasa cuando falla: si el sistema B está caído tres horas, ¿los cambios se pierden, se reintentan o se encolan? Y la tercera es cómo te enteras: si la sincronización deja de funcionar un martes, ¿lo detectas tú con una alerta o lo detecta tu cliente cuando le llega una factura mal?

Un conector estándar resuelve el camino feliz. La integración de verdad es todo lo demás, y todo lo demás es donde se pierde el dinero.

Escenarios reales que nos encontramos

El conector cubre el 80% y el 20% que falta es tu negocio

Es el caso más frecuente y el más frustrante. El conector oficial entre el CRM y el ERP sincroniza clientes, productos y pedidos. Perfecto. Pero resulta que vosotros tenéis descuentos por volumen que se calculan con una regla propia, o un flujo de aprobación cuando el pedido supera cierto importe, o tres tipos de cliente que en el ERP son el mismo campo.

Ese 20% no es un capricho: es exactamente lo que os diferencia de vuestra competencia. Y es justo lo que ningún conector genérico va a contemplar nunca, porque está construido para el denominador común de miles de empresas.

Los dos sistemas dicen cosas distintas sobre el mismo cliente

Aquí el problema no es técnico, es de modelo de datos. En el CRM un cliente es una empresa con varios contactos. En el ERP es un NIF con una dirección de facturación. En la herramienta de soporte es un email. Los tres son “el cliente” y ninguno coincide con los otros.

Antes de escribir una línea de integración hay que decidir la correspondencia, y esa decisión no es del desarrollador: es de negocio. Cuando nos saltamos esa conversación, la integración funciona en pruebas con datos limpios y se rompe el primer día con datos reales.

La sincronización va bien hasta que alguien edita en los dos lados

Una integración unidireccional es un problema de fontanería. Una bidireccional es un problema de concurrencia, y son cosas distintas.

Nos hemos encontrado sincronizaciones que entraban en bucle: el sistema A actualiza a B, B considera que ha habido un cambio y actualiza a A, y así hasta agotar la cuota de la API a las once de la mañana. La solución no es poner un if más: es diseñar desde el principio con marcas de origen y de última escritura, para que cada sistema sepa distinguir un cambio real de su propio eco.

El sistema antiguo no tiene API

Pasa más de lo que parece, sobre todo con software sectorial instalado en un servidor de la oficina. No hay API, hay una base de datos SQL Server a la que “se puede acceder si sabes la contraseña”, y un comercial del fabricante que te ofrece un módulo de integración por una cifra que no encaja en ningún presupuesto.

Aquí la respuesta honesta rara vez es atacar la base de datos directamente, aunque técnicamente se pueda. Escribir en tablas que no son tuyas, sin conocer las reglas internas del producto, es la forma más rápida de corromper datos y quedarte sin soporte del fabricante. Lo que hacemos es construir una capa intermedia que lea de forma segura, exponga una API limpia y escriba solo por los caminos que el fabricante soporta.

El volumen crece y aparecen los límites de la API

Todo funciona en pruebas con cincuenta registros. Luego llega la migración inicial con ochenta mil, o el pico de fin de mes, y descubres que la API del otro lado permite doscientas llamadas por minuto.

Las integraciones que no contemplan esto desde el diseño se convierten en un incidente recurrente. Las que sí lo contemplan usan colas, procesamiento por lotes y reintentos con espera progresiva, y absorben el pico sin que nadie se entere.

Cómo lo abordamos

Primero decidimos quién manda sobre cada dato

Antes de arquitectura y antes de código, hacemos una tabla aburridísima y absolutamente imprescindible: campo a campo, cuál es el sistema que manda. El CRM manda sobre datos comerciales, el ERP sobre datos fiscales y de facturación, la herramienta de soporte sobre el histórico de incidencias.

Esa tabla la valida negocio, no el equipo técnico. Y a partir de ahí, la regla es simple: un campo tiene un dueño y los demás sistemas lo leen. Cuando un campo necesita dos dueños de verdad, se documenta explícitamente y se define la política de resolución de conflictos antes de construir nada.

Elegimos el patrón antes que la tecnología

No todas las integraciones necesitan tiempo real, y el tiempo real es caro de construir y de operar. Distinguimos tres casos:

• Tiempo real por eventos (webhooks). Cuando el dato tiene que estar al otro lado en segundos: un pedido que dispara el picking, un lead que entra y hay que llamar en caliente.
• Cola asíncrona. Cuando el orden importa y el destino puede estar caído. Es el patrón por defecto para la mayoría de integraciones serias entre CRM y ERP.
• Lote programado. Cuando el dato tolera horas de retraso: consolidación contable, informes, catálogos de producto. Es el más barato de construir y de mantener, y muchísimas empresas están pagando una arquitectura de eventos para un problema que se resolvía con un proceso nocturno.

Idempotencia y reintentos desde el diseño

Toda integración va a fallar en algún momento: la red, un despliegue del otro lado, un mantenimiento. La pregunta no es si falla, sino qué pasa después.

Diseñamos cada operación para que ejecutarla dos veces produzca el mismo resultado que ejecutarla una. Suena a detalle técnico menor y es lo que separa una integración que se recupera sola de una que genera pedidos duplicados y una llamada del cliente enfadado. Cada mensaje lleva un identificador único, el destino registra qué ya procesó, y los reintentos son seguros por construcción.

Observabilidad: enterarte antes que tu cliente

Toda integración que ponemos en producción lleva tres cosas: un registro de qué se sincronizó y cuándo, una alerta cuando la cola crece por encima de lo normal, y una pantalla donde alguien de negocio —no de IT— puede ver si hoy ha ido todo bien.

Esa última parte se salta casi siempre y es la que evita el escenario clásico: la integración lleva nueve días caída y nadie se ha dado cuenta porque los errores se escriben en un log que no mira nadie.

Cuándo no hacemos una API a medida

Te lo decimos si es tu caso, aunque signifique un proyecto más pequeño. Si el conector estándar cubre lo que necesitas y tu casuística especial se resuelve con una convención interna, úsalo. Si el volumen es de veinte registros al mes, una persona diez minutos a la semana es más barato que cualquier desarrollo. Y si los dos sistemas van a sustituirse el año que viene, integrar lo que está a punto de morir es tirar dinero.

El desarrollo a medida compensa cuando la lógica que os hace distintos vive precisamente en ese hueco que ningún producto cubre, y cuando el coste del error manual —facturas mal emitidas, stock desincronizado, clientes duplicados— ya supera al del desarrollo.

Errores que conviene evitar

• Empezar por la tecnología en lugar de por el dueño del dato. Elegir la herramienta de integración antes de haber decidido qué sistema manda sobre cada campo garantiza que la reharás.
• Sincronizarlo todo porque se puede. Cada campo sincronizado es un campo que puede desincronizarse. Mueve solo lo que alguien va a usar de verdad al otro lado.
• Probar solo con datos limpios. Los datos de producción tienen teléfonos con formatos raros, nombres duplicados y registros de 2014 sin NIF. Prueba con una copia real antes de salir.
• No pensar la carga inicial. La migración del histórico casi nunca se puede hacer con el mismo mecanismo que el día a día, y descubrirlo el viernes de arranque sale caro.
• Dejar la integración sin dueño. Cuando el proyecto termina, alguien tiene que seguir mirando las alertas. Si esa persona no existe, la integración se degrada en silencio.
• Escribir directamente en la base de datos de un producto de terceros. Funciona hasta que el fabricante actualiza el esquema, y entonces no tienes ni datos ni soporte.

Qué preguntar antes de contratar

Si estás valorando a alguien para esto, hay cuatro preguntas que separan rápido al que ha integrado sistemas en producción del que ha hecho una demo:

1. ¿Qué pasa si el sistema de destino está caído dos horas? (Si la respuesta no menciona colas o reintentos, sigue buscando.)
2. ¿Cómo evitáis duplicados si el mismo mensaje llega dos veces?
3. ¿Quién manda sobre cada campo, y cómo lo decidimos?
4. ¿Cómo me entero yo, sin ser técnico, de que hoy la sincronización ha fallado?

Cierre

En LMNHUB construimos este tipo de integraciones con Python, Django y FastAPI, y llevamos años haciéndolo en escenarios donde el dato importa: conectar Zoho CRM con el ERP, con la centralita o con portales externos, y mantener sistemas que llevan años en producción. Si tienes dos sistemas que deberían hablarse y hoy los une una persona con un Excel, cuéntanos tu caso y te respondemos con un enfoque concreto —qué patrón encaja, qué se sincroniza y qué no— en lugar de con un presupuesto genérico.