Definición y cómo funciona
Una API de datos de mercado es una interfaz de software que entrega información relacionada con el mercado (por ejemplo, cotizaciones, operaciones o barras) desde una o más fuentes de datos a tu aplicación. Antes de evaluar proveedores, separa la mecánica estable (cómo la API representa y transporta los datos) de las condiciones variables (cómo se comporta el mercado subyacente, qué decide publicar el proveedor y con qué frecuencia llegan las actualizaciones). Esto te ayuda a evitar confundir “la API entregó algo” con “los datos son adecuados para tu propósito”.
Los flujos típicos de solicitud/respuesta incluyen autenticación, selección de un endpoint, elección de identificadores de instrumentos, especificación de un rango de tiempo o suscripción, y recepción de cargas útiles que contienen campos más metadatos (a menudo marcas de tiempo e indicadores de estado). Asume que el manejo del tiempo importa: el mismo evento puede aparecer en momentos diferentes según los relojes del proveedor, los retrasos de ingesta y cómo se definen las marcas de tiempo.
Lista de verificación de evidencia: qué verificar
Usa una lista de verificación de debida diligencia y recopila evidencia que puedas revisar por escrito.
- Cobertura de datos e identificadores
- ¿Qué instrumentos están disponibles (y cómo se identifican)? Usa la documentación del proveedor para confirmar los mapeos y los formatos admitidos.
- ¿Están presentes todos los tipos de campos requeridos para tu caso de uso (por ejemplo, bid/ask, última operación, volumen, barras OHLC, series ajustadas por acciones corporativas)?
- Definiciones de campos y normalización
- Confirma las definiciones precisas de cada campo. Por ejemplo, define qué significa “último” en el feed del proveedor y si las barras se basan en operaciones o en cotizaciones.
- Comprueba cómo normaliza el proveedor los símbolos, los decimales, los códigos de moneda y las unidades.
- Marcas de tiempo, zonas horarias y orden
- Verifica qué representa cada marca de tiempo (tiempo del evento vs. tiempo de procesamiento) y el estándar de zona horaria utilizado.
- Prueba el orden: ¿las actualizaciones llegan desordenadas durante la carga y cómo lo señala la API?
- Frecuencia de actualización y modo de entrega
- Determina si la API es de sondeo (solicitud/respuesta) o de transmisión (suscripción). Estos se comportan de manera diferente bajo variabilidad de red.
- Valida la cadencia de actualización esperada y el comportamiento práctico bajo carga, usando tus propios registros de prueba.
- Fiabilidad y modos de fallo Al menos un modo de fallo material debe ser identificado y probado:
- Datos faltantes o vacíos durante interrupciones.
- Reintentos que duplican eventos.
- Límites de tasa que conducen a una cobertura parcial.
- Respuestas de error que no preservan el contexto de la solicitud.
- Límites de tasa, cuotas y factores de costo Incluso sin afirmaciones de precios en vivo, puedes verificar los factores de costo:
- Límites de tasa por clave y si hay límites separados para diferentes endpoints.
- Tamaño de la carga útil (número de instrumentos por solicitud, granularidad de barras) e impacto en el ancho de banda.
- Cualquier restricción de licencia o uso que limite la redistribución o el almacenamiento.
- Relleno histórico y reproducibilidad Si necesitas series históricas, verifica si puedes reproducir el mismo conjunto de datos más tarde:
- ¿Se admite el relleno histórico para un rango de tiempo?
- ¿Son posibles las revisiones de datos y, de ser así, cómo se comunican los valores actualizados?
- Seguridad y comprobaciones de integridad de datos
- Confirma los requisitos del método de autenticación (sin asumir que son suficientes para tu entorno).
- Valida las señales de integridad en las respuestas (por ejemplo, sumas de verificación o indicadores de estado, si se proporcionan) y registra todos los metadatos de las respuestas.
Limitaciones, riesgos y la mentalidad de “señal de alerta”
Los problemas de calidad de los datos de mercado a menudo provienen de desajustes entre lo que asumes y lo que publica el proveedor.
- Inconsistencia de tiempo: Las marcas de tiempo históricas o en tiempo real pueden no alinearse con los relojes de tu sistema, lo que lleva a una secuenciación o ventanas de tiempo incorrectas.
- Interpretación del feed del proveedor: La semántica de los campos puede diferir entre fuentes (por ejemplo, cómo se construyen las barras). Las relaciones históricas pueden fallar porque el comportamiento futuro del mercado cambia y porque el feed puede reflejar diferentes tipos de eventos a lo largo del tiempo.
- Riesgo operativo: Los límites de tasa, la fluctuación de la red o las interrupciones del servicio pueden crear vacíos, duplicados o actualizaciones retrasadas. Estos pueden distorsionar los cálculos posteriores si tratas la llegada de datos como equivalente a la ocurrencia del evento.
- Brecha de verificación: La documentación por sí sola no es evidencia para tu entorno. Realiza pruebas controladas: compara las salidas de muestra con una referencia independiente cuando sea posible y registra las discrepancias.
Un criterio de claridad importante es que puedas explicar tu canalización de datos utilizando supuestos explícitos: qué definición de tiempo usas, cómo manejas los valores faltantes, cómo deduplicas y qué haces cuando se activan los límites de tasa.
Verificación y siguientes preguntas a plantear
Para evaluar de forma independiente, elige un pequeño conjunto de instrumentos representativos y ventanas de tiempo, y luego verifica estos puntos en tus propios registros:
- ¿Las marcas de tiempo cumplen con tus requisitos de secuenciación? - ¿Hay vacíos, duplicados o ráfagas de errores observables bajo un volumen de solicitudes realista?