Permiso de histórico (rechazo del bróker)
El permiso de histórico es el derecho que permite a una cuenta descargar operaciones, barras o profundidad pasadas del servidor de histórico de un bróker, de forma separada de la recepción de datos en directo. Cuando falta, el bróker rechaza la petición con un código de estado como el rp_code 13 de Rithmic («permission denied»), y el gráfico debe mostrar el intervalo como no disponible y no como vacío.
Senzoukria · Glosario · Actualizado en septiembre de 2026
Directo, histórico y profundidad son tres derechos
Una cuenta que recibe operaciones en directo puede ver rechazadas las barras históricas, y una cuenta que devuelve ticks históricos puede carecer de profundidad histórica. Los proveedores venden estas cosas por separado y las alojan en servidores distintos; en Rithmic la plant de histórico es distinta de las de ticker y de órdenes. Una conexión correcta prueba que la cuenta existe en ese sistema y nada sobre lo que puede descargar.
- Operaciones en directo: el derecho de ticker en la plant utilizada.
- Barras y ticks históricos: el derecho de histórico, que puede estar habilitado para uno y no para el otro.
- Profundidad histórica: rara vez disponible en los brókers; el histórico del heatmap necesita actualizaciones del libro grabadas.
- Cada rechazo lleva un código; conserva el código y el intervalo solicitado al preguntar al proveedor.
Leer un rechazo
«Permission denied» al conectar suele significar que la cuenta es desconocida en ese sistema, un problema distinto de un derecho insuficiente; un sistema desconocido se reporta con otro código. Esa misma frase en una petición de histórico significa que el derecho de histórico no está habilitado para ese tipo de dato. Los rechazos también pueden ser intermitentes: una plant sobrecargada puede rechazar parte de una petición y aceptar el reintento. Una petición aceptada que devuelve vacío, sin código de estado, suele significar que el archivo de ese sistema no llega tan atrás o que la plant de histórico está caída.
En Senzoukria
El panel de datos del backtest informa de un relleno rechazado con estas palabras: «El bróker RECHAZÓ la petición: «permission denied» (rp_code 13). Las barras históricas no están habilitadas en esta cuenta — es un derecho del bróker, no un ajuste de la aplicación. Los ticks históricos sí funcionan, y es lo que usa el replay manual.» En el gráfico, el aviso de histórico para un rechazo parcial dice que los rechazos suelen ser intermitentes, que el gráfico sigue funcionando con los datos en caché y en directo, y que reintenta por su cuenta; un intento completado sin código se reporta aparte como archivo vacío. La ayuda de conexión propone la pregunta exacta para el bróker: ¿mi login tiene habilitado el acceso por API de terceros, para qué datos y bajo qué nombre de sistema?
Qué hacer cuando se rechaza el histórico
- No cambies primero de indicadores; anota el símbolo, el vencimiento, la sesión, el estado de la conexión y el código.
- Pregunta al proveedor si las barras históricas y los ticks históricos están habilitados por separado en ese login.
- Usa la caché local: las sesiones ya descargadas siguen abriéndose, desplazándose y calculando.
- Para los backtests, valora una fuente de histórico específica con su propia licencia en lugar del archivo del bróker.
Relacionado
- Checklist del software footprint con Rithmic
- Guía de backtesting de futuros
- Hueco de datos (histórico incompleto)
- Conexión directa (nativa)
Esta página en otros idiomas
Preguntas frecuentes
- ¿Es el rp_code 13 un fallo del software?
- No. Es un estado devuelto por el servidor de histórico del bróker que significa permiso denegado para esa petición. La aplicación puede reintentar y puede seguir funcionando con los datos en caché y en directo, pero no puede conceder el derecho. La solución está del lado de la cuenta, con el proveedor.
- ¿Por qué mi footprint en directo funciona mientras el backtest no puede cargar barras?
- Porque los datos en directo y el histórico son derechos separados. La plant de ticker envía operaciones al gráfico mientras la plant de histórico rechaza la petición de barras. Pide al proveedor que habilite los datos históricos en el login, o usa una fuente de histórico licenciada para ese fin.
- ¿Pueden funcionar los ticks históricos si se rechazan las barras históricas?
- Sí, en algunas cuentas. Las barras y los ticks pueden habilitarse de forma independiente dentro del derecho de histórico. Cuando hay ticks, un replay por ticks o una barra agregada localmente pueden sustituirlas; cuando no hay ninguno de los dos, el intervalo debe quedar marcado como no disponible.