En esta página
Dos patrones de acceso
- Flujo: el cliente se suscribe una vez y recibe cada operación o cada cambio del libro según ocurren, por una conexión persistente como un WebSocket o una sesión TCP.
- Petición y respuesta: el cliente pide un rango, como un día de ticks o un mes de barras de un minuto, y lo recibe en una o varias respuestas.
Qué difiere entre API
| Propiedad | Ejemplos | Por qué importa |
|---|---|---|
| Transporte | WebSocket, TCP, multidifusión UDP, HTTP | Latencia, comportamiento con cortafuegos, recuperación |
| Codificación | Protocol buffers, SBE, JSON, FIX etiqueta-valor | Coste de decodificación, cambios de esquema |
| Contenido | Operaciones con lado agresor, niveles de profundidad, datos orden a orden | Lo que un footprint o una heatmap pueden mostrar |
| Historial | Ticks, barras, profundidad; hasta dónde atrás | Cobertura del Replay y del backtest |
| Permiso | Por mercado, por esquema, por acceso | Lo que tu clave o tu acceso pueden recibir |
Ejemplo resuelto: dimensionar una petición de historial
Las barras de un minuto de un contrato de índice de CME en un día de negociación de 23 horas suman 23 × 60 = 1.380 barras por sesión. Un año de unas 250 sesiones son aproximadamente 1.380 × 250 = 345.000 barras. El mismo año en operaciones individuales es mucho mayor, que es la razón por la que los proveedores limitan el tamaño de las peticiones y por la que las aplicaciones guardan el historial en caché local.
En Senzoukria
La aplicación se conecta a varias API, cada una con su propio permiso: Rithmic por R | Protocol, una interfaz WebSocket abierta con el acceso del propio usuario; Databento con una clave API cuya licencia en vivo se mide por dataset antes de poder activar un módulo; los flujos públicos de Binance y de Bybit sin clave; y los puentes locales de NinjaTrader y de Quantower en los puertos 7272 y 7273. Su ayuda de conexión enuncia la distinción con la que tropieza la mayoría: el acceso a la plataforma y el acceso a la API son dos permisos distintos.
Errores habituales
- Suponer que un acceso que funciona en la plataforma del proveedor funciona también por su API.
- Suponer que el acceso en vivo incluye historial, o que el historial incluye profundidad.
- Elegir el software antes de comprobar qué entrega de verdad la API.
Relacionado
- R | Protocol
- Databento
- Flujo de datos
- Permiso de datos de mercado
- Claves API de proveedores
- Protocolo FIX
En la misma sección
- Apilamiento de liquidez
- Apertura diaria en cripto
- Arbitraje de índice
- Apertura de sesión del CME
- Área de balance
- Anticipación de órdenes
- Área de valor
- Anclaje del CVD
Esta página en otros idiomas
Preguntas frecuentes
- ¿Por qué mi acceso funciona en la plataforma del bróker y no en un software de terceros?
- Porque la plataforma propia del proveedor y su API son permisos distintos. La cuenta puede estar habilitada para uno y no para el otro, algo que solo el bróker o el proveedor pueden confirmar.
- ¿Una API de datos de mercado incluye profundidad histórica?
- Rara vez por defecto. Las operaciones históricas y la profundidad histórica suelen ser productos distintos, y una profundidad que nunca se grabó no puede reconstruirse a partir de las operaciones.