Hay una escena que se repite en casi todas las empresas medianas latinoamericanas que hemos visitado: el equipo de ventas tiene su CRM con los datos de clientes, el equipo de contabilidad tiene su ERP con las facturas y pagos, y alguien está copiando datos manualmente entre los dos sistemas todos los lunes. Esta ineficiencia no es inevitable. Es el resultado de no haber diseñado la integración correctamente desde el inicio.
Los tres patrones de integración empresarial
Antes de hablar de herramientas, hay que entender los patrones fundamentales.
Punto a punto (Point-to-Point)
Cada sistema se conecta directamente con cada otro. Funciona para 2-3 sistemas pero se vuelve un espagueti inmantenible con más sistemas.
CRM ──────────── ERP
│ │
└──── Factura ──┘
Es lo que la mayoría de las empresas implementa primero porque parece lo más simple. El problema aparece cuando tienes 5 sistemas y necesitas 10 conexiones directas (n*(n-1)/2).
Hub-and-Spoke
Un sistema central (hub) coordina todas las integraciones. Cada sistema solo necesita conectarse al hub, no a todos los demás.
CRM ──┐
│
ERP ──┼── HUB ── Warehouse
│
Shop ─┘
Este es el patrón correcto para la mayoría de empresas medianas. Reduce la complejidad de O(n²) a O(n).
ESB (Enterprise Service Bus)
La versión empresarial del hub-and-spoke, con capacidades adicionales de transformación de mensajes, orquestación y gobernanza. Apropiado para grandes corporaciones con docenas de sistemas. Para empresas medianas, es sobre-ingeniería.
REST vs Webhooks vs Message Queues
La elección del mecanismo de comunicación impacta directamente la confiabilidad y el rendimiento.
APIs REST
El mecanismo más familiar. El sistema A llama a la API del sistema B y espera la respuesta. Simple y directo, pero tiene un problema fundamental: si el sistema B está caído cuando A intenta comunicarse, la operación falla.
Úsalo para: consultas de datos donde la respuesta inmediata es necesaria, y cuando los dos sistemas siempre estarán disponibles simultáneamente (lo cual es raro en producción).
Webhooks
El sistema B llama al sistema A cuando ocurre un evento (notificación push vs polling). Más eficiente que polling constante, pero requiere que el sistema receptor sea siempre accesible.
// Endpoint receptor de webhook en Node.js
app.post('/webhook/nuevo-cliente', async (req, res) => {
// Responder inmediatamente para evitar timeout del emisor
res.status(200).json({ received: true })
// Procesar asíncronamente
const { cliente_id, nombre, email } = req.body
try {
await sincronizarClienteEnERP(cliente_id, nombre, email)
await logger.info(`Cliente ${cliente_id} sincronizado`)
} catch (error) {
await logger.error(`Error sincronizando ${cliente_id}`, error)
await encolarParaReintento(req.body)
}
})
Message Queues
La solución más robusta para integraciones críticas. Los mensajes se publican en una cola (RabbitMQ, SQS, Redis Streams) y se procesan de manera asíncrona. Si el consumidor falla, el mensaje permanece en la cola para ser reprocesado.
Para integraciones críticas donde perder un solo evento tiene consecuencias financieras (pagos, facturas, pedidos), las colas de mensajes son el estándar.
Manejo de errores e idempotencia
Este es el tema que más se ignora y el que más quebraderos de cabeza genera en producción.
El problema de la idempotencia
Si tu sistema de integración falla a mitad de procesar un pago, ¿puede procesar el mismo pago de nuevo sin crear un duplicado? Si la respuesta es "no sé" o "no", tienes un problema de idempotencia.
Una operación es idempotente si ejecutarla múltiples veces produce el mismo resultado que ejecutarla una sola vez.
// MAL: crea duplicados si se llama dos veces
async function crearFacturaEnERP(datos: DatosFactura) {
return await erp.facturas.crear(datos)
}
// BIEN: usa el ID externo como clave de idempotencia
async function crearFacturaEnERP(datos: DatosFactura) {
const existente = await erp.facturas.buscarPorIdExterno(datos.id_crm)
if (existente) return existente
return await erp.facturas.crear({
...datos,
id_externo: datos.id_crm // referencia al sistema origen
})
}
Política de reintentos
No todos los errores deben reintentarse de la misma manera. Errores 4xx (Bad Request, Not Found) generalmente no deben reintentarse. Errores 5xx (Server Error) y errores de red sí deben reintentarse con backoff exponencial.
ERPs comunes en LATAM y sus APIs
Cada ERP tiene sus propias particularidades de integración que conviene conocer:
SAP Business One
Tiene Service Layer, una API RESTful bien documentada. Es la forma moderna de integrar. Evita el enfoque antiguo de DI API que requiere instalación local. Autenticación via session token con expiración.
Odoo
API XML-RPC y JSON-RPC nativas. Muy flexible, bien documentada. Amplia comunidad. Es nuestra recomendación para empresas que buscan ERP open-source integrable.
Siigo (Colombia)
API REST relativamente reciente. Permite crear facturas electrónicas, consultar cartera, clientes y productos. Requiere registro de aplicación en su portal de desarrolladores. Algunas limitaciones de rate limiting que hay que manejar.
World Office / Helisa / Contpaq (México)
Menos APIs nativas. Frecuentemente se integra via base de datos directa o exportación/importación de archivos. No ideal, pero es la realidad del mercado.
Herramientas de middleware recomendadas
n8n (self-hosted): Nuestra primera recomendación para empresas con un desarrollador disponible. Puede actuar como hub central, tiene logging integrado y permite manejar transformaciones complejas.
Apache Camel: Para integraciones de alta complejidad empresarial. Curva de aprendizaje alta, pero potencia enorme.
Middleware custom (Node.js/Python): Para integraciones muy específicas o cuando el rendimiento es crítico. Más trabajo inicial pero máximo control.
Los errores más costosos
Sincronización bidireccional sin control de origen: Si el cliente se actualiza en el CRM y en el ERP al mismo tiempo, ¿cuál versión gana? Sin una política clara de "sistema de registro", crearás conflictos sin fin.
Sin manejo de errores en producción: Cualquier integración que no tiene alertas cuando falla, fallará en silencio por semanas sin que nadie lo note.
Transformaciones de datos sin validación: Campos nulos, formatos de fecha distintos, monedas, encoding de caracteres especiales (tildes, ñ). En LATAM estos problemas son especialmente frecuentes.
Integrar directamente a la base de datos: Acceder directamente a la DB del ERP en lugar de su API es rápido de implementar y una pesadilla de mantener. Las actualizaciones del ERP rompen la integración sin aviso.
Conclusión: la integración bien hecha es un activo estratégico
Una arquitectura de integración bien diseñada, con el patrón correcto, manejo robusto de errores e idempotencia, puede ser un motor de eficiencia operativa durante años. Una integración improvisada se convierte en una deuda técnica que frena el crecimiento.
Si estás considerando integrar sistemas en tu empresa o tienes integraciones existentes que causan problemas, en Alternetica ofrecemos diagnósticos de arquitectura de integración. Contáctanos y revisamos tu situación actual sin compromiso.