API REST o acceso directo a base de datos: qué vía elegir para integrar sistemas
Los dos caminos clásicos para conectar sistemas empresariales, con sus riesgos reales: cuándo la API es la vía correcta, cuándo el acceso a base de datos es razonable y por qué escribir directamente en la BD de un ERP casi nunca lo es.
Respuesta corta: si el sistema expone una API que cubre los datos que necesitas, usa la API — es un contrato estable que el fabricante mantiene. El acceso directo a base de datos es razonable para LEER de sistemas veteranos sin API, pero escribir directamente en la base de datos de un ERP es casi siempre mala idea: te saltas su lógica de negocio y puedes corromper datos. Y cuando ninguna vía llega sola, un servicio intermedio combina lo mejor de ambas.
Por qué esta decisión importa más de lo que parece
La vía de conexión determina tres cosas que se pagan durante años: qué se rompe cuando el sistema se actualiza, qué tan seguro es el acceso y quién te puede ayudar cuando algo falla. Elegir por comodidad inicial (“tengo el usuario de la base de datos, tiro por ahí”) es hipotecar la integración.
Vía 1 — La API del sistema
Una API es un contrato: el fabricante define qué se puede pedir y cómo, y se compromete (más o menos) a mantenerlo entre versiones.
A favor:
- Estabilidad: el esquema interno puede cambiar; el contrato de la API, en principio, no.
- Seguridad: permisos definidos, tokens revocables, sin credenciales de base de datos circulando.
- Lógica de negocio incluida: crear un pedido por la API dispara las validaciones y procesos del sistema, igual que si lo tecleara un usuario.
- Soporte: cuando algo falla, el fabricante responde de su API; de tus queries directas, no.
En contra (la letra pequeña que descubres a mitad de proyecto):
- APIs incompletas: muchas cubren catálogo pero no tarifas especiales, clientes pero no sus condiciones de pago. Verifícalo ANTES de decidir, campo a campo.
- Límites de uso: peticiones por minuto que convierten una sincronización masiva en una noche entera.
- Licencias aparte: en varios ERPs, el módulo de API se paga.
- APIs “modernas” solo de nombre: hay APIs que son un volcado XML de 2009 con otro traje.
Cuándo elegirla: siempre que exista y cubra los datos que necesitas con la frescura que necesitas. Es la vía por defecto.
Vía 2 — Acceso directo a la base de datos
Conectarse a la base de datos del sistema y leer (o escribir) sus tablas.
A favor:
- Acceso a todo: si el dato existe, está ahí, sin esperar a que el fabricante lo exponga.
- Sin límites artificiales de peticiones ni licencias de API.
- A menudo, la única opción con sistemas veteranos que no exponen nada más.
En contra:
- El esquema interno no es un contrato. Una actualización del sistema puede renombrar una tabla y romper tu integración sin previo aviso ni changelog.
- Escribir es jugar con fuego. La aplicación valida, calcula y encadena procesos cuando crea un registro; tu INSERT no. Un pedido metido a mano en las tablas puede quedar huérfano de todo lo que el sistema hace alrededor.
- Seguridad más delicada: credenciales de BD con acceso amplio, difíciles de acotar.
- Rendimiento: una query pesada tuya puede ralentizar el sistema a los usuarios reales.
Cuándo es razonable: para lectura, con un sistema sin API, con queries cuidadosas y fuera de horas punta cuando el volumen lo pida. Es una vía legítima que usamos — con respeto.
Cuándo evitarla: para escritura, salvo último recurso absoluto — y entonces, mejor mediante los mecanismos de importación que el propio sistema valide (muchos ERPs veteranos los tienen: ficheros de intercambio, tablas intermedias oficiales), que es en la práctica una tercera vía más segura.
La tabla de decisión
| Criterio | API | BD directa (lectura) | BD directa (escritura) |
|---|---|---|---|
| Estabilidad ante actualizaciones | Alta | Baja | Baja |
| Seguridad / control de acceso | Alta | Media | Baja |
| Cobertura de datos | La que ofrezca | Total | Total |
| Respeta la lógica del sistema | Sí | n/a | No |
| Soporte del fabricante | Sí | No | No |
| Veredicto | Por defecto | Aceptable con criterio | Evitar |
Y cuando ninguna vía llega sola: el servicio intermedio
En integraciones reales lo habitual es combinar: API para lo que la API cubre, lectura de datos para lo que no, ficheros de importación validados para escribir en el veterano. Un servicio intermedio (middleware) centraliza esa mezcla y añade lo que ninguna vía trae de serie: validación antes de aplicar cambios, registro de cada ejecución, reintentos, y avisos cuando algo no cuadra — el enfoque que contamos en cómo integrar un ERP con una aplicación web y que aplicamos en este proyecto de sincronización entre sistemas.
La pregunta correcta no es «¿API o base de datos?» sino «¿qué combinación necesita cada flujo de datos?» — el stock puede ir por API, el histórico por lectura directa y los pedidos por el mecanismo de importación del ERP, todos dentro de la misma integración.
Checklist antes de decidir
- Inventaría qué expone cada sistema: API (¿qué cubre de verdad?), acceso a BD, ficheros, tablas intermedias.
- Lista los datos y su sentido: qué viaja, hacia dónde, con qué frescura.
- Prueba la API contra tus datos reales antes de comprometerte: cobertura y límites.
- Para cada escritura, busca la vía validada por el sistema destino.
- Decide qué pasa cuando falle — porque fallará: registro, avisos, reintentos.
¿Tenéis sistemas que conectar y dudas sobre la vía? Inventariamos lo que exponen y te proponemos la combinación con menos riesgo. Cuéntanos qué sistemas usáis →
Servicio relacionado: Integraciones y automatización
Sobre el autor
Oscar Blanco
Fundador y responsable técnico de MUROSOFT
Desarrollador fullstack con más de una década construyendo software para empresas. En MUROSOFT analiza el proceso antes que la tecnología: qué se hace hoy, qué cuesta y qué merece la pena automatizar. Trabaja de forma directa con quien va a usar el sistema, sin capas intermedias entre el problema y quien lo resuelve.