Cómo conectar un sistema antiguo con apps nuevas sin reemplazarlo (APIs e integración)

Casi toda empresa con algunos años tiene un sistema que "funciona, pero": funciona para lo que fue hecho, pero no se conecta con nada. La tienda en línea tiene su propio inventario, la facturación electrónica se hace en otra pantalla y los reportes se arman copiando datos a una hoja de cálculo.

La reacción natural es pensar en reemplazarlo. A veces es lo correcto, pero muchas veces no hace falta: el sistema antiguo hace bien su trabajo y lo que le falta es una forma de compartir lo que sabe. Esa forma suele ser una API.

Qué es una API, sin tecnicismos

Una API es una puerta de servicio que un sistema abre para que otros le pidan cosas de forma ordenada. En lugar de que una persona entre al sistema, busque el stock de un producto y lo copie en la tienda en línea, la tienda le pregunta directamente al sistema: "¿cuántas unidades hay del producto X?", y recibe la respuesta en un formato que entiende.

Lo importante es que la puerta tiene reglas: quién puede pedir qué, qué datos devuelve y qué pasa si algo falla. Eso es lo que la diferencia de darle a otra aplicación acceso libre a tu base de datos.

Tres formas de conectar un sistema antiguo

No todos los sistemas permiten lo mismo. Según lo que tengas, hay tres caminos, de más a menos recomendable.

1. El sistema ya tiene una API

Algunos sistemas comerciales, incluso los que tienen años, traen una API que nadie aprovechó. Antes de cualquier otra cosa, pregúntale a tu proveedor o revisa la documentación. Si existe, el trabajo consiste en usarla bien.

2. Construir una API alrededor del sistema

Si el sistema no tiene API pero su base de datos es accesible, se puede construir una capa intermedia: una aplicación pequeña que lee y escribe en el sistema antiguo y expone una API moderna hacia afuera. El sistema original no se toca; la capa intermedia hace de traductora.

Esta capa también es el lugar para poner las reglas que el sistema antiguo no tiene: validar datos antes de guardarlos, registrar cada intercambio y reintentar cuando algo falla.

3. Intercambio de archivos

Cuando no hay API ni acceso a la base de datos, todavía queda el intercambio de archivos: el sistema genera un archivo con un formato estable cada cierto tiempo y otro proceso lo lee. Es menos inmediato, pero si el formato no cambia, puede ser confiable.

Si ninguna de las tres opciones es posible, el diagnóstico cambia: lo que hay que resolver probablemente no es la integración, sino la modernización del sistema.

Ejemplos comunes

Estos ejemplos son genéricos, para que veas cómo se aplica la idea. Los detalles cambian en cada empresa.

Facturación electrónica con el SRI

Tu sistema antiguo registra las ventas, pero emitir la factura electrónica es un paso aparte: alguien vuelve a digitar los datos en otro programa. El SRI define el formato de los comprobantes electrónicos en su ficha técnica: cada comprobante se genera como un archivo XML, se firma con tu certificado de firma electrónica y se envía al SRI para su autorización. En Facturador del SRI o sistema de facturación explicamos ese flujo con más detalle.

Con una capa de integración, cada venta registrada en el sistema antiguo pasa al servicio que genera, firma y envía el comprobante, y la respuesta del SRI vuelve al sistema original. Nadie digita dos veces. Lo que hay que diseñar con cuidado es qué pasa cuando el comprobante no se autoriza: dónde queda registrado, quién se entera y cómo se corrige.

Inventario como fuente única

El inventario vive en el sistema antiguo, pero el área de compras lleva su propia hoja de cálculo y el almacén otra. La integración empieza por una decisión que no es técnica: cuál de todos es el dueño del dato de stock. Una vez decidido, los demás dejan de guardar su propia copia y le preguntan al dueño a través de la API.

Esta decisión de "quién es dueño de cada dato" es la base de cualquier integración. La desarrollamos con más detalle en 5 señales de que tus sistemas necesitan integración.

Tienda en línea conectada al sistema de siempre

Abres una tienda en línea y descubres que tiene su propio catálogo, sus propios precios y su propio inventario. Si no se conecta con tu sistema, vas a vender productos que ya no tienes o con precios desactualizados.

Con una API sobre el sistema antiguo, la tienda consulta stock y precios desde la fuente única, y cada pedido vuelve al sistema como una venta más, lista para facturar y despachar. Lo que antes era copiar pedidos a mano pasa a ser un flujo automático, con un registro de cada intercambio para revisar si algo no cuadra.

Qué revisar antes de empezar

Quién es dueño de cada dato

Para cada dato importante (cliente, producto, precio, stock, documento) define qué sistema manda. Sin esa decisión, la integración se convierte en una sincronización en ambos sentidos que produce conflictos difíciles de rastrear.

Qué pasa cuando algo falla

Una integración que casi siempre funciona, pero que de vez en cuando falla en silencio, es peligrosa. Cada flujo necesita reintentos, un registro de errores y alguien que reciba un aviso cuando algo no pasa.

Seguridad de la puerta

La API debe pedir autenticación, dar a cada aplicación solo los permisos que necesita y dejar registro de quién pidió qué. Abrir la base de datos completa a una aplicación externa "porque es más rápido" es un riesgo que no vale la pena.

Documentación

Si la integración solo la entiende quien la construyó, tienes el mismo problema que con el sistema antiguo, en versión nueva. Pide documentación de cada flujo: qué datos viajan, cuándo, en qué formato y qué hacer si falla.

Lista de verificación para tu primera integración

Imprime esta página o copia la lista para revisarla con tu equipo:

1. Sé qué sistema es el dueño de cada dato que se va a compartir.
2. Revisé si el sistema antiguo ya tiene una API o si su base de datos es accesible.
3. Tengo claro el primer flujo a conectar (por ejemplo, ventas hacia facturación).
4. Definí qué pasa cuando un intercambio falla y quién recibe el aviso.
5. La API pide autenticación y cada aplicación tiene solo los permisos que necesita.
6. Cada intercambio queda registrado para poder auditarlo.
7. Hay documentación de cada flujo que entienda alguien distinto a quien lo construyó.
8. Probé el flujo con datos de prueba antes de usarlo con datos reales.

Empieza por un flujo, no por todo

La forma más segura de integrar es elegir el flujo que más trabajo manual te genera, conectarlo bien y verlo funcionar antes de pasar al siguiente. Cada flujo conectado reduce la presión para reemplazar el sistema antiguo y te da tiempo para decidir con calma qué hacer con él.

Si quieres que lo hagamos contigo, nuestro servicio de Integración de Sistemas diseña e implementa APIs y conectores con trazabilidad y monitoreo. Si no tienes claro por dónde empezar, la Evaluación Tecnológica incluye el mapa de integraciones de tu empresa; te contamos qué más revisa en qué es una Evaluación Tecnológica y cuándo conviene hacerla. Y si además estás pensando en mover sistemas fuera de la oficina, lee migrar a la nube en Ecuador.

Para ver en qué punto están tus sistemas, haz el autodiagnóstico tecnológico en 3 minutos. ¿Prefieres contarnos tu caso? Escríbenos.