Qué comprobar al evaluar brokers con API

Define “broker con API” y qué cambia al usar uno

Un broker con API es un servicio de acceso al mercado o de ejecución de operaciones al que te conectas programáticamente (a través de una interfaz de programación de aplicaciones) en lugar de usar una interfaz de operación manual. La diferencia clave es que tu sistema se vuelve responsable de convertir tu intención (instrucciones de orden) en solicitudes reales, manejar las respuestas y reaccionar ante errores.

Para evaluar brokers con API de manera objetiva, trata el problema como dos capas:

Mecánica de integración (estable y comprobable): cómo funciona la autenticación, cómo envías solicitudes, cómo son las respuestas y cómo interpretas los estados de órdenes y ejecución.
Condiciones del mercado y del proveedor (variables): qué sucede durante precios volátiles, liquidez parcial, retrasos de red y reglas y costos de ejecución del lado del proveedor.

Si te centras solo en la parte de la “API”, puedes pasar por alto las incertidumbres más importantes: la calidad de la ejecución y el comportamiento operativo bajo estrés.

Lista de verificación: mecánica de integración que puedes verificar

Utiliza un enfoque basado en evidencia: solicita o inspecciona la documentación y luego prueba con ejemplos controlados.

Autenticación y alcance de la cuenta: Confirma qué credenciales se utilizan, cómo se autoriza el acceso y si las claves de API pueden restringirse por permisos (por ejemplo, solo lectura frente a operación).
Modelo de solicitud/respuesta: Comprueba cómo representa la API las órdenes: tipos de orden, tiempo en vigor, campos obligatorios y la estructura exacta de las respuestas. Define en qué estados puedes confiar y qué campos pueden faltar durante fallos transitorios.
Idempotencia y control de duplicados: Determina cómo evita o resuelve la API los envíos repetidos (por ejemplo, reintentos después de tiempos de espera). Tu sistema debería poder evitar órdenes duplicadas accidentales.
Mapeo del ciclo de vida de la orden y la ejecución: Verifica qué significan “aceptada”, “ejecutada”, “rechazada”, “cancelada” o estados equivalentes. Un riesgo material es la inconsistencia de estado: tu sistema puede creer que una orden está activa mientras el broker ya la ha rechazado.
Límites de velocidad y comportamiento de limitación: Comprueba los límites documentados y qué respuestas indican limitación. Planifica cómo se comporta tu código cuando recibe señales de límite o de contrapresión.
Productos de datos y marcas de tiempo: Si la API proporciona cotizaciones, operaciones o eventos de cuenta, aclara el significado de las marcas de tiempo (hora del servidor frente a hora local) y los supuestos de frecuencia de actualización. Sin esto, no puedes separar la latencia del movimiento del mercado.
Manejo de errores y estrategia de reintentos: Confirma cómo comunica la API los errores (HTTP/red frente a nivel de aplicación). Tus pruebas deberían clasificar los fallos en “seguro de reintentar”, “reintentar con idempotencia” y “no reintentar”.

Evidencia y ejemplos: cómo probar sin asumir resultados

Dado que los resultados varían según las condiciones, utiliza pruebas que midan el comportamiento de tu sistema.

Prueba de integración de caja negra: Envía un pequeño número de órdenes bien definidas y confirma que tu máquina de estados interna coincide con el ciclo de vida reportado por la API.
Simulación de tiempo de espera y reintento (supuesto declarado): Supón que tu llamada de red puede agotar el tiempo de espera después de un umbral determinado (elige un umbral para tu entorno). Luego verifica si reintentar causa duplicados o si las claves de idempotencia (si son compatibles) evitan repeticiones.
Escenario de ejecución parcial (supuesto declarado): Supón que el mercado puede no satisfacer completamente tu tamaño. Prueba cómo detectas la cantidad restante y cómo se entregan las actualizaciones posteriores.
Comprobaciones de orden de eventos: Registra la secuencia de devoluciones de llamada/eventos de la API y compárala con lo que tu código espera. Un modo de fallo es la entrega de actualizaciones fuera de orden, que puede corromper los supuestos en tu seguimiento de órdenes.

Para cada prueba, registra: ID de solicitud, marcas de tiempo (con zona horaria/fuente), cargas útiles de respuesta y resultados finales de conciliación.

Limitaciones y riesgos: al menos un modo de fallo material

Se aplican limitaciones importantes incluso cuando la documentación parece clara:

Fallos operativos: Interrupciones de red, caídas de la API o degradación del servicio pueden causar respuestas faltantes o actualizaciones de estado retrasadas. Tu automatización debe continuar de manera segura durante la incertidumbre.
Ejecuciones parciales y variabilidad de la ejecución: Incluso con una integración correcta, las ejecuciones reales dependen de la liquidez disponible y de la mecánica de ejecución en ese momento.
Discrepancia de estado (modo de fallo material): Tu sistema puede mostrar órdenes “en curso” mientras el broker las ha rechazado o cancelado. Esto puede ocurrir después de tiempos de espera, reintentos o entrega inconsistente de eventos.
Incertidumbre de costos y deslizamiento: Los resultados de ejecución pueden diferir de las relaciones históricas, porque los costos y la calidad de ejecución varían según las condiciones.

Por lo tanto, el propósito de la evaluación no es la predicción, sino la capacidad de conciliar lo que sucedió y detectar discrepancias.

Verificación y siguientes preguntas antes de la automatización

Antes de depender de la automatización con API, exige una respuesta clara y verificable de forma independiente a estas preguntas: