Cómo integrar un ERP con una aplicación web: opciones, arquitectura y errores a evitar

Respuesta corta: casi cualquier ERP se puede integrar con una aplicación web, incluso sin API moderna. Las vías son cuatro — API, acceso a base de datos, intercambio de ficheros y middleware — y la elección correcta depende de qué expone tu ERP, de la frescura de datos que necesitas y de cuánto riesgo puedes asumir. El error grave no suele estar en la vía elegida, sino en conectar los sistemas sin validación, sin registro y sin plan para cuando algo falle.

Antes de la técnica: las tres preguntas de negocio

1. ¿Qué datos y en qué sentido? Productos, precios, stock, clientes, pedidos, facturas… y para cada uno: ¿del ERP a la web, de la web al ERP, o ambos?
2. ¿Cómo de frescos? No es lo mismo publicar el stock “de hace una hora” que impedir vender lo que no hay en tiempo real. Cada nivel de frescura tiene un coste distinto.
3. ¿Quién manda? Cuando la web y el ERP discrepen (y discreparán), ¿qué sistema es la fuente de verdad de cada dato? Nuestra recomendación casi siempre: el ERP manda en precios, stock y clientes; la web manda en lo que nace en ella (el pedido, el registro del usuario).

Con esas tres respuestas, la conversación técnica se vuelve corta.

Las cuatro vías, con sus trade-offs

1. API del ERP

Si el ERP expone una API (REST o similar), suele ser la vía preferente: contrato definido, permisos, y el fabricante la mantiene entre versiones.

• A favor: estabilidad, seguridad, soporte del fabricante.
• En contra: muchas APIs de ERP son incompletas (cubren catálogo pero no tarifas especiales, por ejemplo), tienen límites de uso, o se licencian aparte.
• Cuándo: siempre que exista y cubra los datos que necesitas.

2. Acceso directo a la base de datos

Leer (y a veces escribir) directamente en la base de datos del ERP.

• A favor: acceso a todo, sin límites de la API.
• En contra: es la vía más delicada. El esquema interno no es un contrato: una actualización del ERP puede romperlo todo sin aviso. Y escribir directamente en la base de datos de un ERP puede corromper datos o saltarse su lógica de negocio.
• Cuándo: para lectura, con un ERP antiguo sin API, puede ser perfectamente razonable. Para escritura, solo como último recurso y con mucho cuidado (idealmente usando los mecanismos de importación que el propio ERP valide).

3. Intercambio de ficheros

El método veterano: el ERP exporta/importa ficheros (CSV, XML…) de forma programada.

• A favor: lo soportan hasta los ERPs más antiguos; sencillo de auditar (el fichero es la evidencia).
• En contra: frescura limitada por la frecuencia; requiere gestionar errores de formato y ejecuciones a medias.
• Cuándo: cuando no hay nada mejor, o cuando la naturaleza del dato es de lote (tarifas que cambian una vez al día, por ejemplo). Automatizado y validado, es mucho más digno de lo que su fama sugiere.

4. Middleware (capa intermedia)

Un servicio propio entre el ERP y la web que orquesta la sincronización: lee de un lado por la vía que sea, transforma, valida y escribe en el otro.

• A favor: desacopla los sistemas (si el ERP se cae, la web sigue; los pedidos se encolan), centraliza validación y logs, y permite combinar vías (API para pedidos, ficheros para tarifas).
• En contra: es una pieza más que construir y mantener.
• Cuándo: en cuanto la integración pasa de trivial — más de un flujo de datos, sistemas delicados, necesidad de trazabilidad. En nuestra experiencia, es la arquitectura que acaba teniendo casi cualquier integración seria.

        WEB / APP
            ↕
       MIDDLEWARE     ← validación · cola · registro · avisos
            ↕
   API | BD | ficheros
            ↕
           ERP

Tiempo real vs sincronización programada

La petición inicial casi siempre es “en tiempo real”. La pregunta correcta es: ¿qué pasa si este dato tiene X minutos de antigüedad? Para el stock de un ecommerce con margen, poco; para un catálogo, nada; para confirmar la disponibilidad exacta de la última unidad, mucho.

El tiempo real estricto acopla los sistemas (la web depende de que el ERP responda ya) y multiplica la complejidad. La sincronización programada frecuente + colas para lo que nace en la web cubre la gran mayoría de casos reales con una fracción del riesgo. Reserva el tiempo real para los datos que de verdad lo exigen.

Los errores que vemos repetirse

1. Conectar sin validar. La integración “funciona” hasta que llega el primer dato imperfecto — y los datos reales siempre son imperfectos. Cada lote debe validarse, y los registros problemáticos apartarse y notificarse, no bloquear al resto ni colarse sucios.
2. Sin registro de ejecuciones. Cuando algo no cuadra (“¿por qué este pedido no está en el ERP?”), la respuesta debe estar en un log: qué se movió, cuándo, con qué resultado. Sin eso, cada incidencia es una investigación arqueológica.
3. Sin idempotencia. Si repetir una sincronización duplica pedidos, tienes una bomba. Toda operación debe poder relanzarse sin efectos dobles.
4. La web escribiendo a pelo en el ERP. Saltarse la lógica de negocio del ERP escribiendo directo en sus tablas es la vía rápida a datos corruptos.
5. Dos fuentes de verdad. Si el precio se puede editar en los dos sistemas, tendrás dos precios. Decidir quién manda para cada dato es una decisión de negocio, y va antes que cualquier línea de código.
6. Todo o nada. Intentar sincronizarlo todo desde el día uno. Mejor: el flujo más doloroso primero, en producción, y ampliar desde ahí.

¿Y si mi ERP es antiguo o “no tiene integración”?

Es la situación más común en pymes, y casi nunca es bloqueante: la mayoría de ERPs veteranos permiten al menos lectura de base de datos o intercambio de ficheros, y con un middleware delante se construye una integración sólida sobre esos mimbres. Lo hemos hecho sobre sistemas con décadas de historia. La pregunta no es “¿se puede?” sino “¿qué vía es la razonable y cuánto cuesta mantenerla?”.

Preguntas frecuentes

¿Necesito que mi ERP tenga API para integrarlo? No. Ayuda, pero hay tres vías más. Lo determinante es qué datos necesitas mover y con qué frescura.

¿Cuánto se tarda en integrar un ERP con una web? Una integración acotada (un flujo, un sentido) puede estar en producción en semanas; un proyecto con varios flujos bidireccionales, más. La fase de análisis inicial es la que da la cifra honesta.

¿Qué pasa si el ERP se actualiza? Si la integración va por API oficial, normalmente poco. Si va por base de datos o ficheros, cada actualización del ERP debe probarse contra la integración — otra razón para tener staging y monitorización.

¿Puedo integrar también el CRM, el ecommerce y la web corporativa? Sí — y de hecho el middleware existe para eso: una vez construida la capa, añadir sistemas es incremental.

---

¿Tienes un ERP y una web que no se hablan? Analizamos tus sistemas y te decimos qué vía tiene sentido — con alcance y entregable cerrados. Cuéntanos qué sistemas usáis →

Relacionado: Integraciones y automatización · Caso real: Plataforma B2B conectada al ERP · Caso real: Adiós a las importaciones manuales