Integrar ERP con API REST con un sistema externo: guía técnica para responsables de IT

Resumen: Conectar un ERP a un sistema externo vía API REST es uno de los proyectos técnicos más habituales en pymes que ya tienen software en producción. Este artículo explica el proceso paso a paso, los formatos de intercambio más usados y los fallos que alargan los proyectos varios meses sin necesidad.

Tabla de contenidos

• Qué es una API REST y qué papel juega en la integración de ERP
• Arquitectura típica de una integración ERP con sistema externo
• Formatos de intercambio: JSON, XML y cuándo usar cada uno
• Autenticación y seguridad en la capa de integración
• Los cinco fallos que retrasan los proyectos de integración
• Pasos técnicos para planificar la integración
• Cuándo construir un middleware propio y cuándo no
• TL;DR
• Lecturas recomendadas

Qué es una API REST y qué papel juega en la integración de ERP

Una API REST (Representational State Transfer) es un conjunto de endpoints HTTP que permiten que dos sistemas intercambien datos con un protocolo estándar. En el contexto de un ERP, actúa como puerta de acceso controlada a los datos de negocio: pedidos, stock, facturas, clientes.

Cuando tu ERP expone una API REST, cualquier sistema externo —una tienda online, un SGA, un CRM o una plataforma logística— puede leer o escribir datos sin acceso directo a la base de datos. Eso preserva la integridad del sistema central y mantiene los permisos bajo control.

Lo contrario —acceder directamente a tablas SQL desde un sistema externo— es la causa raíz de muchos proyectos de integración que acaban en pérdida de datos o inconsistencias difíciles de rastrear.

Arquitectura típica de una integración ERP con sistema externo

La mayoría de integraciones entre un ERP y un sistema externo siguen uno de estos tres patrones:

• Integración directa punto a punto: el sistema externo llama directamente a la API del ERP. Sencillo de implementar, pero frágil cuando hay más de dos sistemas involucrados.
• Middleware o bus de integración: una capa intermedia recibe, transforma y enruta los datos entre sistemas. Añade complejidad inicial pero escala bien.
• Cola de mensajes asíncrona: los sistemas publican eventos (por ejemplo, “pedido creado”) y los suscriptores los procesan cuando están disponibles. Reduce el acoplamiento y gestiona picos de carga.

Para una pyme con dos o tres sistemas, la integración directa con un middleware ligero suele ser la opción más eficiente. Proyectos con cinco o más sistemas conectados necesitan un bus de integración desde el principio.

Formatos de intercambio: JSON, XML y cuándo usar cada uno

El formato de intercambio condiciona tanto el rendimiento como el esfuerzo de mantenimiento.

JSON es el estándar de facto en APIs REST modernas. Es más ligero que XML, más legible y tiene soporte nativo en casi todos los lenguajes. Un payload JSON típico para un pedido ocupa entre un 30 % y un 40 % menos que su equivalente en XML.

XML sigue siendo obligatorio en determinados contextos:

• Facturación electrónica bajo el estándar Facturae (necesario para Verifactu)
• Integraciones con sistemas ERP legacy que solo hablan SOAP/XML
• Intercambio con Administraciones Públicas españolas (sede electrónica, SII de la AEAT)

Si tu ERP necesita cumplir con Verifactu, el módulo de facturación debe manejar XML estructurado según el esquema del proyecto de la AEAT, independientemente de que el resto de la integración use JSON.

EDI aparece en sectores como distribución alimentaria o automoción, donde los grandes clientes exigen formatos como EDIFACT o X12. Integrarlo con una API REST requiere una capa de transformación adicional.

Autenticación y seguridad en la capa de integración

Los mecanismos de autenticación más habituales en APIs REST para ERP son:

• OAuth 2.0 con tokens Bearer: estándar actual para APIs que manejan datos sensibles. El token tiene tiempo de vida limitado y se renueva mediante refresh token.
• API Key: más simple de implementar, pero menos seguro si no se gestiona correctamente la rotación. Válido para integraciones internas o entre sistemas propios.
• JWT (JSON Web Token): útil cuando se necesita pasar información de contexto (empresa, permisos) sin consultar la base de datos en cada petición.

Puntos que no son opcionales:

• Toda comunicación debe ir sobre HTTPS con TLS 1.2 mínimo.
• Los tokens y credenciales nunca se almacenan en el código fuente; van en variables de entorno o en un gestor de secretos.
• El ERP debe exponer permisos granulares por endpoint: que un sistema de logística pueda leer stock no significa que deba poder emitir facturas.
• Si los datos incluyen información personal, el diseño de la integración debe considerar el RGPD desde el principio: minimización de datos, logging controlado y acuerdos de encargado de tratamiento firmados.

Los cinco fallos que retrasan los proyectos de integración

Estos son los problemas que más veces alargan un proyecto de integración de dos meses a seis:

1. Documentación de API inexistente o desactualizada. Si el ERP origen no tiene un contrato de API estable (OpenAPI/Swagger), cada cambio en el sistema central puede romper la integración sin previo aviso.

2. No definir el modelo de datos compartido antes de escribir código. Los dos sistemas llaman “cliente” a cosas distintas, o usan codificaciones de producto diferentes. Resolver esto durante el desarrollo cuesta el triple que hacerlo en papel antes de empezar.

3. Ignorar la gestión de errores y los reintentos. Una integración síncrona sin lógica de reintento falla en silencio cuando el sistema destino está caído. Los datos se pierden y nadie lo detecta hasta que el problema ya es grande.

4. No contemplar el volumen real de datos. Una sincronización que funciona con 500 pedidos/día falla con 5.000 si la paginación y los límites de rate no están bien configurados.

5. Mezclar entornos de pruebas y producción. Utilizar credenciales de producción para pruebas de integración es más común de lo que parece y ha causado pérdidas de datos reales en proyectos mal gestionados.

Pasos técnicos para planificar la integración

Un proceso ordenado reduce el riesgo sin alargar el proyecto:

1. Inventariar los sistemas involucrados y definir cuál es el sistema de registro (source of truth) para cada entidad de datos.
2. Documentar los flujos de datos: qué datos, en qué dirección, con qué frecuencia y qué desencadena cada intercambio.
3. Revisar las APIs disponibles en ambos lados: endpoints existentes, versión, autenticación soportada, límites de peticiones.
4. Definir el modelo de datos canónico que usará la integración, con mapeos explícitos entre los campos de cada sistema.
5. Diseñar la gestión de errores: qué pasa si un sistema no responde, cómo se registran los fallos y quién recibe la alerta.
6. Implementar en un entorno de pruebas con datos reales anonimizados, no con datos ficticios que no representen el volumen real.
7. Validar el rendimiento bajo carga antes de pasar a producción.
8. Documentar la integración para que el equipo interno pueda operar y depurar sin depender del proveedor para cada incidencia.

Cuándo construir un middleware propio y cuándo no

Un middleware propio tiene sentido cuando:

• Hay tres o más sistemas que necesitan comunicarse entre sí.
• Los formatos de origen y destino son muy diferentes y la transformación es compleja.
• Necesitas auditoría completa de cada intercambio de datos por razones legales o de negocio.
• El volumen de transacciones justifica el coste de desarrollo y mantenimiento.

No tiene sentido cuando:

• Solo conectas dos sistemas con un flujo unidireccional simple.
• El proveedor del sistema externo ofrece un conector nativo para tu ERP que cubre el caso de uso real.
• El presupuesto y el tiempo disponibles hacen que la integración directa sea suficiente para los próximos dos o tres años.

En Rowan Tech hemos construido integraciones para ERP propios, plataformas de comercio electrónico, sistemas de logística de terceros y herramientas de firma digital. La decisión entre middleware y conexión directa siempre parte del inventario de sistemas y del volumen de datos, no de una preferencia tecnológica a priori.

Si trabajas con Rowan ERP o necesitas conectarlo a tu stack actual, la API está documentada con OpenAPI y los endpoints cubren las entidades principales: pedidos, artículos, clientes, facturas y movimientos de almacén. Lo mismo aplica a Rowan SGA, que expone eventos de entrada, salida y trazabilidad en tiempo real para que cualquier sistema externo los consuma.

Si tu operativa incluye entregas con firma, Rowan Rutas puede integrarse con tu ERP para cerrar el ciclo desde el pedido hasta la confirmación de entrega con validez legal, sin intervención manual.

TL;DR

• Una API REST permite que un sistema externo lea y escriba datos en tu ERP sin acceso directo a la base de datos.
• JSON es el formato estándar; XML sigue siendo obligatorio para facturación Verifactu e integraciones con la AEAT.
• OAuth 2.0 es el mecanismo de autenticación recomendado para APIs de ERP con datos sensibles.
• Los proyectos se retrasan principalmente por documentación ausente, modelos de datos no alineados y falta de gestión de errores.
• Un middleware solo se justifica cuando hay tres o más sistemas conectados o cuando la transformación de datos es compleja.

Lecturas recomendadas

• Rowan ERP: ERP a medida para pymes con API abierta
• Rowan SGA: gestión de almacén con trazabilidad en tiempo real
• Rowan Analytics: Business Intelligence conectado a tu ERP o base de datos