Integrar dos sistemas con APIs incompletas, datos viejos o procesos manuales rara vez consiste en enviar información de uno al otro. El trabajo empieza cuando ambos interpretan los datos de manera distinta, aplican reglas diferentes o fallan a mitad del flujo. Una integración no consiste en conectar A con B. Consiste en decidir qué pasa cuando A y B no están de acuerdo.
Cuando el problema está entre herramientas que ya existen, podemos ayudarte con integraciones API sin asumir que hay que reemplazar toda la plataforma.
El problema casi nunca es hacer la primera conexión
Obtener una respuesta correcta de una API suele ser la parte fácil. Hacés una petición, recibís un 200 OK, los datos llegan y parece que lo difícil ya pasó. Pero una integración no tiene que funcionar una vez. Tiene que seguir funcionando cuando cambian los datos, cuando un servicio externo deja de responder o cuando aparece un caso que nadie contempló al principio.
La diferencia está ahí. Una prueba exitosa demuestra que dos sistemas pueden comunicarse. No demuestra que puedan convivir.
Primero hay que entender quién manda
Supongamos que dos sistemas comparten información de productos. En uno cambia el precio. En el otro también puede editarse. ¿Cuál es correcto? Lo mismo puede pasar con clientes, inventario, pedidos, suscripciones o cualquier otro dato compartido. Antes de desarrollar la integración hay que definir una fuente de verdad para cada tipo de información.
Puede ser que el sistema A sea responsable del inventario y el sistema B de los datos comerciales. Eso está bien. El problema aparece cuando los dos pueden modificar lo mismo y nadie definió qué dato tiene prioridad. Si esa decisión no existe, el código termina tomándola por accidente.
Los identificadores importan más de lo que parece
El mismo producto puede ser 1832 en una plataforma, tener un SKU en otra y un identificador completamente distinto en un servicio externo. Mientras todo coincide, no pasa nada. Después alguien modifica un SKU, se duplica un producto o aparece un registro viejo y la sincronización deja de saber qué corresponde con qué.
Una integración necesita una forma estable de relacionar entidades entre sistemas. No alcanza con que los nombres se parezcan. Tampoco conviene asumir que un identificador interno va a existir del otro lado. Definir bien esas relaciones al principio evita muchos problemas que, meses después, parecen errores misteriosos de sincronización.
Una API documentada no significa una API predecible
La documentación es el punto de partida, no necesariamente la realidad completa. Puede haber campos que aparecen vacíos aunque parezcan obligatorios, endpoints que responden distinto según el estado del objeto, límites de solicitudes que recién se vuelven visibles con volumen real o comportamientos que directamente no están documentados.
También existen APIs viejas, APIs que cambiaron varias veces y sistemas donde una parte de la información todavía depende de procesos manuales. Por eso una integración no debería diseñarse solamente alrededor del caso ideal. Hay que observar cómo se comporta realmente el sistema.
¿Tiempo real o sincronización?
"Tiempo real" suena mejor, pero no siempre es necesario. Hay procesos donde un webhook inmediato tiene sentido. Por ejemplo, si una operación necesita disparar otra acción apenas ocurre. En otros casos, sincronizar cada algunos minutos puede ser más simple y suficientemente rápido.
La pregunta no debería ser cuál arquitectura parece más avanzada. La pregunta es cuánto puede esperar ese dato sin afectar el negocio. Si cinco minutos no cambian nada, diseñar una infraestructura mucho más compleja para conseguir cinco segundos probablemente no tenga sentido.
Hay que asumir que algo va a fallar
Un servicio externo puede caerse. Una petición puede tardar demasiado. Un webhook puede llegar dos veces. Un registro puede quedar procesado a mitad de camino.
Una credencial puede vencer. Nada de eso es excepcional. Es parte normal de trabajar con sistemas distribuidos. Por eso conviene pensar desde el principio en reintentos, operaciones idempotentes, registros de errores y alguna forma clara de recuperar procesos fallidos. El artículo sobre qué ocurre después del primer 200 OK profundiza en esos mecanismos.
También tiene que ser posible responder una pregunta bastante básica:
¿Qué pasó con este registro?
Si para averiguarlo hay que revisar manualmente tres bases de datos y buscar entre miles de líneas de logs, la integración todavía tiene trabajo pendiente.
No hay que esconder procesos rotos detrás de automatización
A veces el pedido inicial es integrar dos sistemas, pero al revisar el flujo aparecen planillas intermedias, datos duplicados y personas copiando información de un lugar a otro.
Reglas que todos conocen pero que nunca fueron escritas. Excepciones que existen porque hace cinco años alguien necesitó resolver un caso puntual. Automatizar todo eso sin revisarlo primero puede dejar un sistema técnicamente integrado, pero igual de difícil de mantener. Automatizar un proceso roto solamente permite ejecutar el problema más rápido.
Antes de escribir código vale la pena entender por qué el flujo funciona de esa manera y qué partes todavía tienen sentido.
Ese análisis también ayuda a reconocer cuándo Excel deja de alcanzar y conviene pasar a software a medida, en lugar de automatizar una planilla que ya sostiene demasiadas reglas.
Una buena integración debería volverse aburrida
Cuando una integración está bien resuelta, con el tiempo deja de llamar la atención: los datos llegan, los procesos corren y los errores quedan registrados.
Las operaciones pueden reintentarse. Y cuando algo falla, alguien puede entender qué ocurrió sin tener que reconstruir toda la historia a mano. Eso suele ser una mejor señal de calidad que la cantidad de tecnologías involucradas. Una integración robusta no necesita parecer sofisticada. Necesita ser predecible.
Conectar es solo el principio
Integrar sistemas viejos, nuevos, propios y de terceros no requiere necesariamente una arquitectura enorme. Requiere entender bien los datos, definir responsabilidades, elegir qué sistema decide cada cosa y asumir desde el comienzo que eventualmente algo va a fallar. La conexión entre A y B es apenas el primer paso. La integración queda resuelta cuando sus decisiones, fallos y recuperaciones son predecibles para quien tenga que operarla.