Mi ERP no tiene API: ¿puedo automatizar igual?

Introducción

Es una de las primeras frases que aparece cuando una pyme se plantea automatizar algo: "nuestro programa de gestión es antiguo y no tiene API". Suele decirse en tono de disculpa, como si cerrara la conversación.

No la cierra. La mayoría de los sistemas de gestión que hay instalados en empresas españolas se pueden integrar de una forma u otra, aunque el fabricante nunca haya publicado una interfaz de programación. La pregunta útil no es si el ERP tiene API, sino qué vías de entrada y salida de datos ofrece, cuáles están soportadas por el fabricante y cuánto cuesta mantenerlas cuando el sistema se actualice.

Este artículo repasa esas vías, en qué orden conviene considerarlas y dónde están los riesgos reales. La conclusión adelantada es incómoda para quien vende integraciones: en muchos casos se puede automatizar bastante sin tocar el ERP, y en unos pocos la respuesta honesta es que no compensa.

Cuántas empresas están en esta situación

Conviene situar el problema. Según los datos de Eurostat correspondientes a 2025, el 46,45 % de las empresas de la Unión Europea con diez o más empleados utiliza un sistema de planificación de recursos empresariales para compartir información entre áreas (Eurostat, 2025). España está bastante por encima de la media, con un 60,38 %.

El dato relevante para este artículo es otro: el reparto por tamaño. Entre las empresas pequeñas la adopción es del 41,08 %, mientras que en las grandes alcanza el 88,71 % (Eurostat, 2025). Es decir, cuatro de cada diez empresas pequeñas europeas trabajan con un ERP, y ese ERP rara vez es el mismo producto que usan las grandes corporaciones.

Ahí está el origen del problema. El software de gestión instalado en pymes suele ser vertical, muy adaptado al sector, a veces desarrollado por una empresa local, y con frecuencia lleva más de una década funcionando. Cumple su función. Lo que no tiene es una interfaz pensada para que otros programas hablen con él, porque cuando se diseñó nadie preveía esa necesidad.

Qué significa realmente "no tiene API"

"No tiene API" puede querer decir cosas muy distintas, y merece la pena distinguirlas antes de dar nada por perdido:

• El fabricante nunca desarrolló una interfaz de programación.
• Existe, pero solo para algunos módulos, o está sin documentar.
• Existe y está documentada, pero el fabricante cobra aparte por habilitarla.
• Existe en la versión actual del producto, y la empresa usa una anterior.

Los dos últimos casos son más frecuentes de lo que parece y no son problemas técnicos, sino comerciales. Antes de diseñar ninguna alternativa, la pregunta que hay que hacerle al fabricante es exactamente esa: si existe alguna forma soportada de leer y escribir datos, y en qué condiciones.

Merece la pena preguntarlo por escrito. Una vía soportada por el fabricante, aunque sea limitada y fea, vale más que una solución ingeniosa que él no reconoce: cuando algo falle (y algo fallará) la diferencia entre tener soporte o no tenerlo es lo que determina cuánto dura la avería.

Las vías de integración, de menos a más frágil

Cuando no hay API, quedan varias alternativas. No son equivalentes, y el orden en que se consideran importa.

Exportación programada de ficheros

Prácticamente todos los sistemas de gestión permiten sacar informes en formatos como CSV, Excel o XML. Si esa exportación se puede programar (o lanzar desde una tarea automática) se dispone de una vía de salida de datos estable y de bajo riesgo.

Es menos elegante que una API, pero tiene dos virtudes considerables: no modifica nada dentro del ERP y no depende de conocer sus tripas. Para la mayoría de automatizaciones que necesita una pyme, con un volcado diario o cada pocas horas basta. El tiempo real se pide mucho más de lo que se necesita.

Su punto débil es que el formato del informe puede cambiar sin aviso al actualizar el sistema. Conviene que el proceso que lee el fichero valide su estructura y avise cuando no encaje, en lugar de seguir adelante con datos mal interpretados.

Acceso de solo lectura a la base de datos

Si el ERP se apoya en una base de datos estándar, consultarla directamente en modo lectura es la vía más potente de todas: permite acceder a cualquier dato sin esperar a que alguien exporte un informe.

También es la que más criterio exige. El esquema de datos rara vez está documentado, los nombres de tabla suelen ser crípticos y las relaciones entre ellas no siempre son evidentes. Una consulta mal planteada no rompe nada, pero puede devolver cifras equivocadas, que es peor: un error visible se corrige, uno silencioso se propaga.

Dos condiciones antes de tomar este camino. La primera, confirmar con el fabricante que el acceso de lectura no invalida el soporte. La segunda, y no negociable: solo lectura. Nunca escritura.

Ficheros de intercambio y módulos de importación

Muchos sistemas de gestión incorporan módulos de importación pensados para contabilidad, para intercambio con gestorías o para EDI con grandes clientes. Son interfaces estables, documentadas y soportadas, precisamente porque el fabricante las diseñó para que las usaran terceros.

Suelen pasar desapercibidas porque no se llaman "API", pero para meter datos en el ERP son la mejor opción disponible. Aquí hay además una tendencia normativa que juega a favor: la Ley 18/2022 estableció la obligación de emitir factura electrónica en las operaciones entre empresas y profesionales, con un despliegue por fases que fija su desarrollo reglamentario (España, 2022). Cualquier ERP que siga operativo tendrá que producir y consumir documentos estructurados, y esos mismos mecanismos sirven para otras integraciones.

El correo como transporte

Si el ERP puede enviar informes por correo de forma programada, ese correo se puede procesar automáticamente. Es poco vistoso y funciona sorprendentemente bien: no toca el sistema, no requiere permisos especiales y sobrevive a las actualizaciones.

Tiene sentido como solución puente o para volúmenes moderados. Como arquitectura definitiva para un proceso crítico, se queda corta.

Automatización de la interfaz

La última opción es un programa que maneja el ERP como lo haría una persona: abre pantallas, rellena campos, pulsa botones. Es la más frágil de todas. Cualquier cambio en la interfaz la rompe, es lenta, y depurarla cuando falla resulta trabajoso.

Sirve para tareas acotadas, de volumen bajo y sin urgencia, o como puente mientras se implanta algo mejor. Sostener un proceso crítico sobre esta base es acumular una deuda que se paga entera el día que el fabricante cambia una pantalla.

Errores que salen caros

Escribir directamente en la base de datos. Es el más grave. Un ERP aplica validaciones, actualiza tablas relacionadas y mantiene consistencia contable. Escribir por debajo se salta todo eso: los datos parecen correctos y el sistema queda incoherente por dentro. Además, casi ningún fabricante mantiene el soporte de una instalación manipulada así.

Confundir una demostración con una integración. Que un script lea un fichero de ejemplo no significa que el proceso funcione con la variedad real de datos, con los casos raros y con los meses de cierre.

No presupuestar el mantenimiento. Toda integración sin API depende de supuestos (el formato del informe, el nombre de una tabla, la posición de un campo) que el fabricante puede cambiar. Una integración de este tipo no se entrega y se olvida: hay que vigilarla, y eso tiene un coste recurrente que debe estar en el presupuesto desde el principio.

Sacar más datos de los necesarios. Volcar tablas completas "por si acaso" a un sistema externo multiplica la superficie expuesta sin necesidad. Los marcos de buenas prácticas en ciberseguridad insisten en conceder los permisos mínimos imprescindibles para cada caso de uso (ENISA, 2023). Aplicado aquí: exportar los campos que hacen falta, no el fichero de clientes entero.

Cómo decidir

Tres preguntas ordenan la mayoría de los casos.

¿Hace falta leer o escribir? Leer es sencillo y de bajo riesgo; casi cualquier vía sirve. Escribir es donde aparecen los problemas, y donde conviene limitarse a mecanismos soportados por el fabricante. Muchas automatizaciones útiles solo necesitan leer: informes, alertas, cuadros de mando, preparación de documentos.

¿Qué latencia necesita el proceso de verdad? Si un volcado cada hora resuelve el problema, no hay razón para asumir la complejidad del tiempo real.

¿Cuánto se mueve el ERP? Un sistema que se actualiza dos veces al año exige integraciones robustas. Uno congelado desde hace cinco años admite soluciones más pegadas a su estructura, con el riesgo distinto de que el día que se actualice se rompa todo a la vez.

Y una advertencia sobre la solución que primero propone mucha gente: cambiar de ERP. A veces es lo correcto, pero es una decisión de una magnitud completamente distinta (meses de proyecto, migración de datos, reaprendizaje del equipo) y rara vez se justifica solo por poder automatizar dos procesos. Conviene agotar antes las vías descritas y comprobar cuánto del problema queda realmente sin resolver.

La respuesta corta a la pregunta del título es que sí, casi siempre se puede automatizar sin API. La larga es que la vía elegida determina cuánto durará funcionando, y esa es la parte que conviene decidir con calma.

Referencias

ENISA. (2023). Multilayer framework for good cybersecurity practices for AI. Agencia de la Unión Europea para la Ciberseguridad. https://www.enisa.europa.eu/publications/multilayer-framework-for-good-cybersecurity-practices-for-ai

España. (2022). Ley 18/2022, de 28 de septiembre, de creación y crecimiento de empresas. Boletín Oficial del Estado. https://www.boe.es/buscar/act.php?id=BOE-A-2022-15818

Eurostat. (2025). E-business integration. Statistics Explained. https://ec.europa.eu/eurostat/statistics-explained/index.php?title=E-business_integration