Integrar una app con sistemas existentes: API, webhooks y sincronización

Pocas empresas parten de cero. Ya tienen un sistema de gestión, una planilla, un programa de facturación o una tienda online, y la nueva app tiene que convivir con todo eso. Una integración con sistemas existentes es el trabajo de hacer que dos programas intercambien datos sin que nadie tenga que copiarlos a mano. Suele ser la parte menos visible y más impredecible de un proyecto.

Las formas más comunes de integrar

Mecanismo	Cómo funciona	Cuándo conviene
API REST	Una app le pide datos a otra, o se los envía, mediante direcciones y formatos acordados	El otro sistema ofrece una API documentada
Webhooks	El sistema ajeno avisa a la app cuando ocurre un evento, en lugar de esperar a que le pregunten	Se necesita reaccionar rápido a cambios, como un pago aprobado
Exportación e importación de archivos	Se generan o se leen archivos CSV o planillas de forma periódica	El sistema ajeno es antiguo o no tiene API
Acceso directo a la base de datos	Se lee o escribe en las tablas del otro sistema	Último recurso: es frágil y puede romper garantías del proveedor

Si querés entender mejor qué es una API en sí, hay una explicación aparte en la guía sobre APIs.

Lo que hay que averiguar del sistema ajeno

El mayor error es estimar una integración sin haber visto el otro lado. Antes de comprometer alcance, conviene responder:

1. ¿Tiene API? ¿Está documentada y es oficial, o hay que deducirla?
2. ¿Quién es el proveedor y está dispuesto a darnos acceso y soporte?
3. ¿Hay un ambiente de pruebas separado del real?
4. ¿Cómo se autentica el acceso y cuánto duran las credenciales?
5. ¿Existen límites de uso, es decir, cuántas consultas se permiten por minuto?
6. ¿Qué datos expone y cuáles no? A veces lo que necesitamos simplemente no está disponible.
7. ¿Con qué frecuencia cambia y cómo avisan de los cambios?

Una integración depende de un sistema que no controlamos. Si el proveedor modifica o retira su API, hay que adaptar la integración. Verificá qué condiciones de uso y soporte ofrece el sistema ajeno.

Sincronización: la parte difícil

Mover un dato una vez es fácil. Mantener dos sistemas consistentes en el tiempo no lo es. Hay que decidir:

• Cuál es la fuente de verdad de cada dato. Si el precio vive en el sistema de gestión, la app lo lee pero no lo edita.
• Dirección: en un sentido (uno manda, el otro recibe) o en ambos. La sincronización bidireccional exige resolver qué pasa cuando los dos cambian el mismo dato a la vez.
• Frecuencia: en tiempo casi real, cada tanto o bajo demanda. Cuanto más inmediata, más complejidad.
• Identificadores: cómo se reconoce que un cliente de un sistema es el mismo del otro, por ejemplo por documento o por un código común.

Errores: planificarlos desde el principio

Las integraciones fallan. El otro servidor se cae, vence una credencial, llega un dato con formato inesperado. Un diseño responsable incluye:

• Reintentos automáticos con esperas crecientes, para fallas transitorias.
• Cola de pendientes, para que una caída del otro lado no haga perder operaciones.
• Idempotencia: que repetir un mismo envío no genere duplicados, por ejemplo dos pedidos iguales.
• Registro de eventos consultable, para saber qué se envió y qué respondieron.
• Avisos al responsable cuando algo no se pudo resolver solo.

Estas piezas no se ven en una demo, pero marcan la diferencia entre una integración que funciona el primer día y una que funciona todos los días.

Impacto en el alcance y el costo

El esfuerzo no depende de «cuántas integraciones» sino de la calidad de cada una: una API clara con ambiente de pruebas es una cosa; un sistema sin documentación, donde hay que ensayar y errar, es otra muy distinta. También pesan la cantidad de datos a mover, la dirección de la sincronización y el manejo de errores. Por eso es sensato separar la exploración técnica del desarrollo: primero investigar, después presupuestar con más certeza. Parte de esta lógica vive en el backend de la solución.

Riesgos habituales

• Depender de un proveedor que no responde o que cambia sin aviso.
• Exponer credenciales de terceros dentro de la app en lugar de guardarlas en el servidor.
• Descubrir tarde que un dato imprescindible no está disponible.
• No definir quién se hace cargo cuando la falla está del lado ajeno.

Un caso frecuente en Argentina es la conexión con facturación; lo tratamos en facturación electrónica.

Siguiente paso

Si tu proyecto tiene que conectarse con algo que ya usás, mandanos qué sistema es y qué datos querés mover. Desde Rosario podemos revisar la viabilidad antes de comprometer un alcance: escribinos desde el formulario de contacto.