Integraciones B2B con APIs de datos: cómo negociar SLAs que el pipeline pueda cumplir
Integraciones B2B con APIs de datos: cómo negociar SLAs que el pipeline pueda cumplir
El acuerdo está firmado. El equipo comercial ha prometido disponibilidad del 99,9 %, latencia por debajo de dos segundos y datos "en tiempo real". Tres semanas después, el equipo de ingeniería descubre que esos compromisos no tienen ningún correlato en la arquitectura que han heredado. El SLA existe en el contrato, no en el sistema.
Este escenario se repite con más frecuencia de lo que se documenta. En integraciones B2B con APIs de datos, el problema no suele ser la falta de voluntad técnica: es que los SLAs se negocian fuera del flujo de diseño. Quien firma el contrato no es quien construye el pipeline. Y quien construye el pipeline llega tarde.
La consecuencia es deuda técnica invisible: compromisos que el sistema no puede honrar y que solo se hacen evidentes cuando el cliente escala una incidencia.
El SLA no es un porcentaje: es una cadena de dependencias
Hablar de disponibilidad del 99,9 % tiene sentido si la métrica está bien delimitada. ¿Disponibilidad de qué? ¿Del endpoint de consulta? ¿Del procesamiento subyacente? ¿De la entrega de señales procesadas?
En una integración B2B con APIs de datos, la cadena típica incluye al menos cuatro eslabones:
- Disponibilidad de la fuente upstream (fuentes públicas, APIs de terceros).
- Procesamiento interno (Text and Data Mining, normalización, enriquecimiento semántico).
- Disponibilidad del endpoint que expone el equipo proveedor.
- Capacidad de consumo del cliente (timeouts, reintentos, lógica de fallback).
Un SLA que solo mide el punto 3 da una falsa sensación de control. Si la fuente upstream cae o el procesamiento introduce latencia no prevista, el endpoint puede responder con un 200 OK devolviendo datos obsoletos. El contrato técnico se cumple en papel; el cliente recibe basura.
El primer paso en cualquier negociación técnica seria es mapear esta cadena completa y asignar métricas específicas a cada eslabón. No un único número, sino un conjunto articulado de indicadores.
Qué debe definir un contrato técnico antes de firmarse
Un buen contrato técnico de integración B2B no es un anexo de cinco líneas. Debe responder, al menos, estas preguntas:
- Latencia máxima por tipo de consulta. Las consultas históricas y las de señal reciente tienen perfiles de latencia completamente distintos. Mezclarlos en un único SLA es una trampa.
- Ventana de actualización de datos. ¿Con qué frecuencia se actualizan las señales procesadas? ¿Cada minuto? ¿Cada hora? Si el cliente asume tiempo real y el sistema opera en ventanas de 15 minutos, el desajuste aparecerá en producción.
- Política de reintentos y comportamiento ante errores transitorios. Un 429 (rate limit) no es lo mismo que un 503 (servicio no disponible). El contrato técnico debe especificar cómo el cliente debe comportarse ante cada código de respuesta y qué garantías ofrece el proveedor sobre la recuperación.
- Definición de "incidencia". ¿Una degradación del 30 % en throughput activa el SLA? ¿Solo la indisponibilidad total? Esta ambigüedad es la fuente de la mayoría de disputas técnicas entre equipos.
- Proceso de escalada técnica. No el teléfono del account manager: el canal directo al equipo de ingeniería del proveedor, con tiempos de respuesta acordados.
Sin estas definiciones por escrito, cualquier número de disponibilidad es decorativo.
Cómo traducir compromisos comerciales a restricciones de diseño
Cuando el equipo de ingeniería llega tarde a la negociación, la solución no es aceptar los compromisos heredados: es traducirlos a restricciones de diseño concretas y documentar qué arquitectura los hace posibles (o imposibles).
Algunos patrones útiles:
Buffers de escritura con TTL controlado. Si el SLA exige disponibilidad del 99,9 % pero la fuente upstream tiene ventanas de mantenimiento no anunciadas, un buffer local con TTL explícito permite servir datos recientes sin depender de la fuente en cada llamada. El cliente sabe que puede recibir datos con N minutos de antigüedad; el proveedor puede cumplir el SLA de disponibilidad sin mentir sobre la frescura.
Circuit breakers diferenciados por criticidad de señal. No todas las señales tienen el mismo valor operativo. Un circuit breaker que paraliza todo el pipeline ante la degradación de una fuente secundaria es un diseño excesivamente conservador. Clasificar las señales por criticidad permite aislar fallos sin romper el SLA global.
Health endpoints con granularidad real. Un /health que devuelve {"status": "ok"} no informa de nada útil. Un health endpoint bien diseñado expone la latencia actual por tipo de consulta, el estado de cada fuente, el lag de procesamiento y el throughput de los últimos cinco minutos. El cliente puede integrar esos datos en su propio sistema de alertas y detectar degradaciones antes de que impacten en el SLA.
El coste oculto de los SLAs que nadie mide
Los equipos técnicos B2B tienden a obsesionarse con el uptime y a ignorar otra métrica igualmente crítica: la tasa de completitud de datos. Un endpoint puede estar disponible al 100 % y devolver señales con una cobertura del 60 % respecto al universo de fuentes acordado. El sistema funciona; el análisis que el cliente construye sobre él es incorrecto.
En integraciones orientadas a análisis de menciones, tendencias o monitorización del universo público de Internet, la completitud es tan importante como la latencia. Un pipeline que procesa el 100 % de las fuentes acordadas en 30 segundos es más valioso que uno que procesa el 60 % en 5 segundos, dependiendo del caso de uso.
Esta métrica raramente aparece en los SLAs comerciales porque es más difícil de medir y de comunicar. Pero es exactamente la que el equipo de ingeniería del cliente va a notar cuando sus modelos empiecen a producir resultados anómalos.
Herramientas como FeedScale permiten auditar esta completitud mediante consultas programáticas: comparar el volumen de señales recibido contra el esperado según el perfil histórico de las fuentes. No como sustituto del SLA formal, sino como capa de observabilidad que el equipo técnico puede instrumentar de forma autónoma.
Integra primero, firma después
La regla práctica que más frecuentemente se ignora en integraciones B2B: prueba el sistema en condiciones reales antes de comprometer un SLA.
Esto no siempre es posible en el ciclo comercial, pero sí es exigible en el periodo de piloto. Un piloto bien instrumentado debe producir datos sobre latencia real, tasa de error, comportamiento bajo carga y completitud de señales. Esos datos son la base sobre la que se negocia el SLA definitivo.
Un SLA que emerge de un piloto real es defendible. Uno que emerge de una hoja de especificaciones es, en el mejor caso, una estimación optimista.
Los equipos técnicos que entienden esto tienen una ventaja clara en la negociación: pueden señalar exactamente qué compromisos son alcanzables y cuáles requieren inversión adicional en infraestructura. No como obstáculo, sino como información de diseño.
La integración B2B no termina cuando el contrato se firma. Empieza ahí. Y la única forma de que el pipeline sobreviva en producción es que los compromisos que aparecen en el contrato hayan pasado antes por las manos del equipo de ingeniería.