Qué hacer cuando una de tus aplicaciones no tiene API

Es una de las preguntas que más aparecen al plantear una automatización. La empresa tiene un programa que funciona bien, que lleva años en producción y que el equipo conoce, pero el fabricante no ofrece API o cobra por ella una cifra que no encaja con el proyecto.

La buena noticia es que casi siempre hay salida. La menos buena es que no todas las salidas son igual de sólidas, y elegir la equivocada significa reconstruir la integración cada vez que el proveedor publica una actualización.

1. Acceso directo a la base de datos

Si el programa guarda sus datos en una base de datos accesible, se puede leer de ahí. Es la vía más rápida y la más tentadora.

Para lectura suele ser razonable: consultar pedidos, clientes o stock sin tocar nada. Para escritura es peligroso, porque el programa aplica reglas de negocio que no están en la base de datos —cálculos, validaciones, tablas relacionadas que hay que actualizar a la vez—. Escribiendo directamente se salta todo eso.

2. Importación y exportación por ficheros

Muchos programas sin API sí tienen importadores y exportadores: CSV, Excel, XML, a veces formatos EDI. Es una vía menos elegante pero notablemente estable, porque esos formatos los mantiene el fabricante y rara vez cambian sin avisar.

Funciona bien cuando el proceso tolera trabajar por lotes: sincronizar el catálogo cada noche, volcar los pedidos del día, actualizar tarifas una vez por semana. No sirve cuando se necesita reaccionar al instante.

3. Base de datos intermedia

Algunos programas permiten definir tablas o vistas propias donde depositar información para que otro sistema la recoja, y viceversa. Es un punto intermedio interesante: se gana estabilidad frente al acceso directo, porque esa zona es territorio acordado y no estructura interna del fabricante.

4. Automatización sobre la interfaz

Consiste en que un proceso automático haga lo mismo que haría una persona: abrir la aplicación, rellenar campos, pulsar botones. Es lo que se conoce como RPA.

Resuelve casos que ninguna otra vía alcanza, pero es la opción más frágil del conjunto: cualquier cambio en la pantalla rompe el proceso, y ese cambio llega sin avisar en la siguiente actualización. Es una solución legítima cuando no hay otra, siempre que se asuma que va a necesitar mantenimiento recurrente.

5. Cambiar la pregunta

A veces la mejor integración es la que no se construye. Si el programa cerrado solo aporta una función que ya cubre otro sistema del que sí se tiene control, puede salir más barato mover ese proceso que integrarlo.

No siempre es viable, pero merece ponerse sobre la mesa antes de invertir meses en conectar algo que a lo mejor sobra.

Cómo elegir

El criterio no es qué vía es más fácil hoy, sino cuál sobrevive a la próxima actualización del proveedor. Ordenadas de más a menos duraderas:

1. Exportación e importación por ficheros con formato documentado.
2. Zona de intercambio acordada con el fabricante.
3. Lectura directa de base de datos.
4. Escritura directa de base de datos.
5. Automatización sobre la interfaz.

Sea cual sea la elegida, hay tres cosas que no son opcionales: registro de cada ejecución, control de errores con reintentos, y un aviso a una persona concreta cuando algo falla. Una integración que falla en silencio hace más daño que no tenerla, porque el error se descubre semanas después y ya con consecuencias.

La pregunta no es si se puede integrar, sino cuánto va a costar mantenerlo.