Transformación Digital
¿Cómo conectar los sistemas de una empresa mediante APIs?
Respuesta directa
Conectar sistemas por API implica decidir si cada par de aplicaciones se comunica directamente (punto a punto) o a través de una capa de integración central, definir cómo se autentican, versionar los contratos, controlar los límites de tasa, manejar reintentos de forma idempotente y monitorear cada llamada. Sin esas reglas, las integraciones se vuelven frágiles y difíciles de mantener conforme crecen.
Una API (interfaz de programación de aplicaciones, del inglés Application Programming Interface) es el conjunto de reglas que permite que un sistema pida datos o acciones a otro de forma controlada. Cuando una empresa tiene más de dos o tres sistemas —CRM, ERP, facturación, ecommerce, herramientas internas—, la pregunta deja de ser «¿podemos conectarlos?» y pasa a ser «¿con qué arquitectura los conectamos para que siga siendo mantenible en dos años?». Esta guía describe las decisiones de diseño que determinan esa diferencia.
Conexión punto a punto vs. capa de integración
La conexión punto a punto conecta cada sistema directamente con cada otro sistema que necesita. Es rápida de construir cuando hay pocas integraciones, pero el número de conexiones crece de forma combinatoria: con seis sistemas conectados entre sí pueden llegar a existir quince enlaces distintos, cada uno con su propia autenticación, formato de datos y lógica de errores.
Una capa de integración (middleware) centraliza esa comunicación: cada sistema se conecta una sola vez a la capa, y la capa se encarga de enrutar, transformar y distribuir la información hacia los demás. Herramientas de iPaaS (Integration Platform as a Service) como las de Microsoft Azure, Google Cloud o plataformas especializadas cumplen este papel. El costo es una pieza adicional que administrar; el beneficio es que agregar un sistema nuevo no implica reescribir las conexiones existentes.
Relacionado: ¿Qué hacer cuando un sistema no tiene API?
Cómo fluyen los datos entre sistemas
Un flujo típico de integración sigue un recorrido con pasos identificables, donde cada etapa puede fallar de forma independiente y por eso necesita registro y control propio.
Sistema A → API de salida → capa de integración → transformación de datos → API de entrada → Sistema B → logs y monitoreo
La etapa de «transformación» existe porque los sistemas rara vez usan el mismo formato: un campo llamado «cliente_id» en un sistema puede llamarse «customerId» en otro, o un monto puede venir en centavos en uno y en pesos en otro. Esa traducción debe documentarse explícitamente, no dejarse implícita en el código.
Para elegir el mecanismo a partir del síntoma, revisa cómo evitar copiar y pegar información entre sistemas.
Relacionado: ¿Cómo integrar un CRM con un ERP?
Si estás evaluando cómo ordenar esta transformación dentro de tu empresa, así trabajamos la arquitectura de ecosistemas digitales.
Autenticación, llaves y control de acceso
Toda API debe verificar quién hace la llamada antes de responder. Los métodos más comunes son las llaves de API (API keys), tokens con el protocolo OAuth 2.0 (RFC 6749) y certificados mutuos para integraciones de alta sensibilidad. La llave o token debe tratarse como una contraseña: no se comparte en código fuente, se rota periódicamente y se revoca de inmediato si un sistema deja de usarse.
Además de autenticar, es necesario autorizar: que un sistema esté identificado no significa que deba poder leer y modificar todo. Definir permisos por tipo de operación (lectura, escritura, borrado) y por conjunto de datos limita el daño si una llave se filtra.
- OAuth 2.0
- Estándar abierto (definido en el RFC 6749 del IETF) que permite que una aplicación obtenga acceso limitado a los recursos de otra sin manejar directamente las contraseñas del usuario.
Relacionado: ¿Cómo conectar un ERP con inteligencia artificial?
Versionado de contratos y límites de tasa
Una API cambia con el tiempo: se agregan campos, se corrigen errores, se retiran funciones antiguas. Versionar el contrato (por ejemplo, exponer «/v1/» y «/v2/» en paralelo) evita que una actualización rompa integraciones que ya están en producción. El estándar OpenAPI, mantenido por la OpenAPI Initiative, es la forma habitual de documentar ese contrato de manera que humanos y herramientas puedan leerlo por igual.
Los límites de tasa (rate limits) restringen cuántas llamadas puede hacer un sistema en un periodo determinado, para proteger la estabilidad del servicio. Cuando una integración los excede, la API suele responder con el código HTTP 429 («Too Many Requests»); el sistema que llama debe esperar y reintentar, no simplemente insistir de inmediato.
| Elemento | Para qué sirve | Ejemplo |
|---|---|---|
| Número de versión | Permitir cambios sin romper integraciones existentes | /v1/pedidos, /v2/pedidos |
| Documentación OpenAPI | Describir endpoints, campos y errores de forma estándar | Archivo openapi.yaml |
| Política de descontinuación (deprecation) | Avisar con anticipación antes de retirar una versión | "v1 deja de operar en 6 meses" |
Relacionado: ¿Cómo conectar datos de diferentes sistemas de una empresa?
Reintentos, idempotencia y monitoreo
Las redes fallan: una llamada puede no llegar, tardar demasiado o perder la respuesta aunque el sistema receptor sí procesó la solicitud. Por eso las integraciones necesitan reintentos automáticos, pero un reintento mal diseñado puede duplicar una acción (por ejemplo, cobrar dos veces o crear dos pedidos idénticos).
La idempotencia resuelve ese riesgo: es la propiedad de una operación que produce el mismo resultado sin importar cuántas veces se repita con los mismos datos. Se implementa habitualmente asignando un identificador único a cada solicitud, de modo que el sistema receptor reconozca y descarte los duplicados. Finalmente, todo lo anterior debe ser observable: registrar cada llamada, su resultado y su tiempo de respuesta permite detectar fallas antes de que afecten al negocio, no después.
Antes de dar por lista una integración
- El contrato de la API está documentado y versionado
- Las llaves o tokens no están escritos en el código fuente
- Existe una política de reintentos con espera progresiva (backoff)
- Las operaciones críticas son idempotentes
- Hay alertas activas ante errores o caídas de la integración
Fuentes
Relacionado: ¿Cómo integrar un ERP, CRM e inteligencia artificial?
Preguntas frecuentes
- ¿Siempre conviene usar una capa de integración en lugar de punto a punto?
- No. Con muy pocas conexiones, punto a punto es más simple y rápido de implementar. La capa de integración se justifica cuando el número de sistemas conectados crece y mantener conexiones individuales empieza a consumir más esfuerzo del que ahorra.
- ¿Qué pasa si una API no tiene límites de tasa documentados?
- Hay que asumir que existen aunque no estén publicados y diseñar la integración para llamar con moderación, capturar el código de error correspondiente y reintentar con espera progresiva, en lugar de descubrir el límite en producción.
- ¿La idempotencia se configura del lado de quien llama o de quien recibe la API?
- En ambos: quien llama debe generar un identificador único por solicitud, y quien recibe debe reconocer ese identificador para descartar duplicados. Si la API no lo soporta, hay que construir esa protección en la capa de integración.
- ¿Cómo se documenta una integración para que otra persona pueda mantenerla después?
- Con un contrato en formato OpenAPI, un diagrama del flujo de datos entre sistemas, el detalle de autenticación y permisos, y un registro de decisiones sobre transformación de campos y manejo de errores.
Más artículos de esta categoría Transformación Digital
- ¿Qué debe incluir un diagnóstico de automatización e inteligencia artificial?
- ¿Cómo construir un roadmap de inteligencia artificial para una empresa?
- ¿Qué industrias pueden obtener más valor de la automatización con inteligencia artificial?
- ¿Cómo priorizar casos de uso de inteligencia artificial por industria?