Integraciones B2B con APIs de datos: lo que el contrato técnico no cubre pero el sistema sí exige

Integraciones B2B con APIs de datos: lo que el contrato técnico no cubre pero el sistema sí exige

Una integración B2B que funciona en staging es una promesa. Una integración que aguanta seis meses en producción es otra cosa: es arquitectura real. El salto entre ambas no lo cubre ningún documento de especificación. Lo cubre la experiencia de haber visto dónde fallan los sistemas cuando el proveedor hace algo que no incumple su contrato, pero que destruye tu pipeline.

Este post no trata de qué conectar ni con qué protocolo. Trata de qué esperar más allá del contrato formal y cómo diseñar la integración para que resista esas fricciones invisibles.

El contrato técnico dice qué. El sistema real dice cuándo, cuánto y con qué varianza

Cuando un proveedor de datos documenta su API, describe el contrato estructural: endpoints, métodos, esquema de respuesta, códigos de error. Lo que rara vez documenta es el comportamiento estadístico del sistema:

• Latencia media vs. latencia en percentil 95.
• Tasa de respuestas parciales en momentos de carga.
• Frecuencia real de actualización de los datos frente a la frecuencia nominal.
• Comportamiento del rate limiter cuando te aproximas al límite, no cuando lo superas.

Estos parámetros son los que rompen las integraciones B2B. No porque el proveedor incumpla: simplemente porque el contrato nunca los recogió y el equipo receptor asumió valores que nunca fueron garantizados.

La acción concreta: antes de integrar, mide. Pon un proxy entre tu sistema y la API del proveedor durante al menos dos semanas en un entorno que replique el patrón de carga real. Recoge percentiles de latencia, tasa de errores 5xx, variabilidad en el volumen de respuesta. Esos datos te darán el contrato real, no el documentado.

Las dependencias ocultas que nadie mapea al principio

Una integración B2B con una API de datos rara vez es una conexión punto a punto. Detrás del endpoint que consumes hay decisiones de infraestructura del proveedor que no controlas: caches, CDNs, pipelines de enriquecimiento propios, servicios de terceros que el proveedor usa internamente. Cuando uno de esos eslabones falla, tu sistema recibe datos inconsistentes, respuestas degradadas o silencio absoluto.

El problema real no es que esto ocurra. Es que la mayoría de los equipos receptores no tienen visibilidad de qué eslabón falló. Ven un timeout o un payload inesperado, pero no saben si el problema está en la capa de red, en el enriquecimiento del dato o en el sistema de almacenamiento del proveedor.

Lo que funciona en la práctica:

1. Fingerprinting de respuestas. Registra no solo el código HTTP sino el tamaño del payload, el tiempo hasta el primer byte y la estructura del JSON de primer nivel. Anomalías en esos indicadores revelan fallos intermedios antes de que el dato corrompa el pipeline.
2. Contrato de datos propio. Define internamente qué campos son obligatorios, qué rangos de valores son válidos y qué volumetría mínima esperas. Valida contra ese contrato en la capa de ingestión, no en la de análisis.
3. Canal de comunicación operacional con el proveedor. Un email de soporte no es suficiente. Una integración B2B seria necesita un canal con tiempo de respuesta garantizado para incidencias que afectan a producción.

Transformación de datos: el cuello de botella que no aparece en el diagrama de arquitectura

La mayoría de los diagramas de integración B2B tienen una caja etiquetada "transformación" o "normalización". Esa caja oculta la mayor fuente de deuda técnica en integraciones de datos públicos.

Los datos que llegan de fuentes externas traen su propia semántica: fechas en formatos inconsistentes, campos opcionales que unas veces vienen y otras no, valores nulos codificados de tres maneras distintas, cadenas de texto con encodings mezclados. Cada uno de esos casos requiere una decisión explícita. Cuando no se toma, el código de transformación acumula ifs silenciosos que nadie documenta y que fallan cuando aparece un caso nuevo.

El patrón que escala: separar la normalización estructural (tipos, encodings, fechas) de la normalización semántica (entidades, categorías, relaciones). La primera es mecánica y se puede automatizar casi por completo. La segunda requiere lógica de negocio y debe ser explícita, versionada y testeable de forma independiente del pipeline.

Cuando trabajas con APIs como las de FeedScale, que entregan análisis derivado de fuentes públicas, la transformación semántica es especialmente crítica: los datos ya vienen procesados, pero tu modelo interno de entidades puede diferir del modelo del proveedor. Mapear esa diferencia explícitamente desde el principio ahorra semanas de debugging posterior.

SLAs de disponibilidad: qué negocias y qué aceptas sin saberlo

Un SLA del 99,5% de disponibilidad mensual significa aproximadamente 3,6 horas de caída permitida al mes. Si tu integración procesa datos en tiempo casi real, esas 3,6 horas pueden concentrarse en un momento crítico y tu sistema no tendrá datos para operar. El SLA se habrá cumplido. Tu cliente interno, no.

Lo que hay que negociar explícitamente:

• Ventanas de mantenimiento. ¿Cuándo pueden ocurrir? ¿Con qué preaviso mínimo?
• Degradación gradual vs. caída total. ¿El sistema entra en modo degradado o cae de golpe?
• Datos de recuperación. Cuando el servicio vuelve, ¿los datos del período de caída están disponibles o se han perdido?

Este último punto es el más ignorado. Muchos proveedores de APIs de datos no ofrecen backfill automático tras una incidencia. Si tu pipeline no tiene lógica de recuperación propia (ventana de reintentos, almacenamiento de referencias temporales, marcadores de gap), los datos de ese período sencillamente no existirán en tu sistema.

El momento en que la integración "funciona" no es el momento en que termina

Una integración B2B no termina cuando los tests pasan ni cuando el primer dato llega al destino. Termina, si es que termina, cuando el equipo receptor tiene visibilidad operacional real: sabe cuándo el dato llega tarde, cuándo el volumen es anómalo, cuándo un campo cambia de comportamiento.

Eso exige observabilidad desde el día uno, no como capa posterior. Cada integración debería tener tres métricas básicas siempre visibles: frescura del dato (cuánto tiempo lleva el último registro recibido), completitud (qué porcentaje de los registros esperados llegaron en la última ventana) y tasa de rechazo en validación (qué porcentaje no pasó el contrato de datos propio).

Sin esas tres métricas, operar una integración B2B en producción es volar sin instrumentación. El sistema puede estar fallando silenciosamente durante horas antes de que alguien lo note.

La integración robusta no es la que nunca falla. Es la que falla de forma visible, controlada y recuperable. Esa es la diferencia que separa los pipelines que duran de los que se reescriben cada año.

← Volver al blog