Integraciones B2B con APIs de datos: lo que nadie te dice antes de llegar a producción
Integraciones B2B con APIs de datos: lo que nadie te dice antes de llegar a producción
El problema no suele aparecer en el sandbox. Aparece tres semanas después del go-live, cuando un proveedor cambia un campo sin avisar, el volumen de respuestas triplica lo esperado y el equipo de guardia no tiene claro a quién llamar primero.
Las integraciones B2B con APIs de datos externos son uno de esos problemas que parecen resueltos en fase de desarrollo y se vuelven costosos en producción. No porque la tecnología falle, sino porque la mayoría de los equipos tratan la integración como un problema de conexión cuando, en realidad, es un problema de contrato, de operación y de cambio continuo.
Este post no es una introducción a las APIs REST. Es una guía de lo que suele fallar, cuándo falla y cómo mitigarlo desde el diseño.
El error más caro: confundir disponibilidad con fiabilidad
Un endpoint que responde con 200 OK no es un endpoint fiable. En integraciones B2B de datos, la diferencia entre disponibilidad y fiabilidad es donde se pierden horas de debugging y se generan incidentes en cascada.
La disponibilidad te dice si el servidor responde. La fiabilidad te dice si el dato que devuelve es coherente, completo y dentro del rango esperado. Un proveedor puede devolver siempre 200 con un payload vacío, con un campo null donde antes había un string, o con una paginación que cambia de comportamiento según el volumen de resultados.
Antes de integrar cualquier API de datos en un pipeline productivo, el equipo debería definir al menos tres cosas:
- Qué campos son críticos y cuáles son opcionales. Si tu lógica de negocio depende de un campo concreto, necesitas validación explícita en el consumer, no en el productor.
- Cuál es el rango de volumen esperado por llamada. Las variaciones extremas (respuestas con 0 resultados o con 10x el máximo habitual) son síntomas de algo, no ruido.
- Qué significa un dato "fresco" en tu contexto. Algunas APIs actualizan en tiempo real; otras, con latencia de horas. Integrar ambas sin tenerlo en cuenta genera inconsistencias silenciosas.
Contratos de dato: el documento que casi nadie escribe
En integraciones B2B maduras, el contrato entre sistemas no es el acuerdo comercial. Es la especificación técnica de qué datos fluyen, con qué estructura, con qué frecuencia y con qué garantías de estabilidad.
La mayoría de los equipos trabajan con la documentación pública del proveedor como si fuera un contrato. No lo es. La documentación describe el comportamiento esperado, no garantiza nada sobre cambios futuros ni sobre comportamientos edge.
Un contrato de dato real debería incluir:
- Schema versionado: si el proveedor actualiza un campo, tu sistema debe saber qué versión está consumiendo.
- SLA de latencia diferenciado por endpoint: no todos los endpoints tienen el mismo coste de proceso. Los que implican análisis sobre texto o grandes volúmenes tienen latencias distintas a los que devuelven metadatos simples.
- Política de deprecación: cuánto tiempo de antelación da el proveedor antes de retirar un campo o cambiar un comportamiento. Si no existe política documentada, ese riesgo debe aparecer en tu arquitectura.
- Comportamiento ante rate limiting: qué headers devuelve, si usa 429 o 503, si el backoff es fijo o exponencial.
Si el proveedor no tiene esto documentado, no es necesariamente una señal de descarte — pero sí de que debes instrumentar más agresivamente tu propio consumer.
Resiliencia desde el diseño, no como parche
El patrón más común en integraciones B2B problemáticas es la resiliencia añadida como parche. El equipo integra, llega a producción, aparece un timeout, y entonces alguien añade un retry. Aparece un pico de rate limiting, y entonces alguien añade un circuit breaker. El resultado es una capa de resiliencia construida como respuesta a incidentes, no como parte del diseño.
Algunos patrones que vale la pena implementar desde el primer día:
Dead letter queue para payloads no procesables. Si el consumer recibe un dato que no puede parsear, debe almacenarlo para revisión posterior, no descartarlo silenciosamente ni bloquear el pipeline.
Validación de schema en la capa de ingesta. Antes de que el dato llegue a cualquier transformación o almacenamiento, una capa ligera de validación (JSON Schema, Pydantic, Avro según el stack) que emita métricas sobre anomalías. No para bloquear, sino para observar.
Separación entre disponibilidad del proveedor y disponibilidad de tu servicio. Tu sistema no debería caerse porque una API externa no responde. El fallback puede ser sirviendo datos cacheados, una respuesta degradada o un mensaje de estado — pero la decisión debe ser tuya, no una consecuencia pasiva de lo que haga el proveedor.
El problema del cambio sin versión
Una de las fuentes de incidentes más frecuentes en integraciones de larga duración es el cambio sin versión. El proveedor añade un campo, cambia el tipo de otro, o modifica el comportamiento de filtrado — sin incrementar la versión del endpoint.
No todos los proveedores versionan bien sus APIs. En el ecosistema de datos del universo público de Internet, donde las fuentes cambian de formato o de estructura con frecuencia, este es un riesgo real y operativo.
La mitigación no es solo técnica. Requiere un proceso en el equipo: tests de contrato automatizados que se ejecuten periódicamente contra el entorno productivo del proveedor, no solo en CI. Si el schema cambia, el test lo detecta antes de que lo haga el usuario.
Herramientas como Pact, Dredd o incluso un script de validación propio pueden cumplir esta función. Lo importante es que el test se ejecute de forma continua, no solo antes del despliegue.
Pay-as-you-go y control de gasto en integraciones de datos
Las APIs de datos con modelo pay-as-you-go añaden una variable que las integraciones de SaaS tradicionales no tienen: el coste es proporcional al uso real, lo que significa que un bug en el consumer puede generar un gasto inesperado antes de que nadie lo detecte.
Un loop mal implementado, un retry sin límite o una query que devuelve 10x los resultados esperados pueden disparar el consumo en horas. En plataformas como FeedScale, donde el modelo es por volumen de datos procesados, esto tiene implicaciones directas en facturación.
La respuesta técnica es instrumentación agresiva desde el primer día: métricas de llamadas por unidad de tiempo, alertas sobre volumen de resultados por encima del percentil 95, y un hard limit de llamadas por hora mientras el sistema está en fase de rodaje.
Antes de firmar la integración, pregunta esto
Si tu equipo está evaluando una integración B2B con un proveedor de datos, hay cinco preguntas que deberían tener respuesta documentada antes de comprometerse:
- ¿Con cuánta antelación se notifican los cambios de schema o comportamiento?
- ¿Cuál es el comportamiento exacto ante rate limiting (headers, códigos, tiempos)?
- ¿Existe un entorno de staging o sandbox con datos representativos del volumen productivo?
- ¿Qué garantías ofrece el SLA sobre latencia de ingesta, no solo sobre uptime del servidor?
- ¿Cómo se comporta la API ante consultas que devuelven cero resultados? ¿Es un 200 vacío, un 404, un código propio?
Ninguna de estas preguntas es exótica. Todas aparecen en el primer incidente productivo si no se responden antes.
Las integraciones B2B de datos son infraestructura crítica. Tratarlas como una tarea de configuración es el primer paso hacia una deuda técnica que no se ve hasta que cuesta demasiado.