Cómo Integrar APIs en Tu Negocio

Una integración por API sirve para que un dato deje de escribirse dos veces. El caso típico de una pyme es concreto: un pedido que entra en la tienda y alguien vuelve a teclear en el programa de facturación, y otra vez en la hoja de stock. Ahí no se pierde solo tiempo, se generan discrepancias que nadie sabe cuál es la buena.

Antes de integrar conviene medir el proceso manual: cuántas veces al día ocurre, cuánto se tarda y con qué frecuencia falla. Si son diez minutos a la semana, automatizarlo cuesta más que hacerlo. Si son dos horas al día y hay errores, la integración se paga sola en semanas.

• Pedidos de la tienda hacia el sistema de facturación
• Stock del almacén hacia el catálogo de la web
• Formularios de contacto hacia el CRM comercial
• Cobros de la pasarela hacia la contabilidad
• Datos de clientes hacia la herramienta de email

La decisión que ahorra más problemas después es cuál es la fuente de verdad de cada dato. Si el precio de un producto se puede editar en la tienda y en el ERP, antes o después divergen y la integración se convierte en una guerra de sobrescrituras. Un dato, un sitio donde se edita, y el resto lo recibe.

La segunda decisión es la dirección: si la sincronización va en un sentido o en los dos. La bidireccional es mucho más cara de construir y de depurar, y la mayoría de los casos reales se resuelven en un solo sentido si se ha decidido bien la fuente de verdad.

• Qué sistema manda sobre cada campo, escrito y acordado
• Sincronización en un sentido siempre que sea posible
• Qué hacer cuando los dos lados cambian a la vez
• Con qué frecuencia hace falta que el dato esté al día
• Qué pasa con lo histórico que ya está desincronizado

Hay dos formas de enterarse de que algo ha cambiado en el otro sistema. Preguntar cada cierto tiempo es simple y funciona en cualquier sitio, pero gasta llamadas y llega tarde. Los webhooks avisan en el momento y son mucho más eficientes, pero exigen una URL pública accesible y verificar que quien llama es quien dice ser.

Un detalle práctico que se descubre tarde: los webhooks se entregan más de una vez. La red falla, el emisor reintenta, y el mismo aviso llega dos o tres veces. Si el receptor no está preparado, un pedido se duplica y un cobro se contabiliza dos veces.

• Consulta periódica: simple, sin URL pública, con retraso
• Webhooks: inmediatos y eficientes, exigen endpoint público
• Verifica siempre la firma del webhook antes de procesarlo
• Asume que llegará repetido y guarda el identificador del evento
• Responde rápido y procesa después, en una cola

Toda integración falla alguna vez: el otro sistema se cae, cambia un campo o devuelve un error de límite de peticiones. La diferencia entre una integración buena y una frágil no es que no falle, es qué hace cuando falla. Reintentar con esperas crecientes y un tope, y dejar en una cola aparte lo que no se pudo procesar.

La pieza que evita los desastres es la idempotencia: que procesar el mismo mensaje dos veces produzca el mismo resultado que procesarlo una. Se consigue guardando el identificador de cada evento ya tratado y descartando los repetidos antes de tocar nada.

• Reintentos con espera creciente y un número máximo
• Identificador de evento guardado para descartar repetidos
• Cola de fallidos que alguien revisa de verdad
• Aviso cuando la cola de fallidos crece, no cuando ya es tarde
• Registro de qué se envió y qué se recibió, para poder auditarlo

Una clave de API es una contraseña con todos los permisos de la cuenta, y se filtra con una facilidad sorprendente: en un repositorio, en el JavaScript del navegador o en una captura enviada por chat. La regla operativa es que las claves viven solo en el servidor, en variables de entorno, y nunca se envían al frontend.

Además conviene pedir el permiso mínimo que necesite la integración y rotar las claves con cierta periodicidad. Si la API lo permite, credenciales distintas por entorno y por integración: así una filtración se acota y se puede revocar sin parar todo lo demás.

• Claves solo en el servidor, nunca en el código del navegador
• Variables de entorno y nunca en el repositorio
• Permiso mínimo necesario para lo que hace la integración
• Credenciales distintas para pruebas y producción
• Rotación periódica y revocación inmediata ante sospecha

Una integración no se entrega y se olvida: depende de un sistema de otro que cambia sin avisarte. Las APIs se versionan, se retiran versiones antiguas y se modifican campos. Conviene suscribirse al canal de cambios del proveedor y saber qué versión estás usando y hasta cuándo tiene soporte.

Lo que realmente marca la diferencia es la vigilancia. Una integración rota en silencio es peor que una caída visible: los pedidos siguen entrando, nadie los ve pasar al otro lado y el problema se descubre cuando el descuadre ya lleva semanas.

• Suscríbete al registro de cambios del proveedor
• Sabe qué versión usas y hasta cuándo tiene soporte
• Alerta cuando dejan de llegar eventos, no solo cuando fallan
• Cuadre periódico entre los dos sistemas, aunque sea semanal
• Documenta qué campo va a dónde para quien venga después