History permission (broker refusal)

History permission is the entitlement that lets an account download past trades, bars or depth from a broker's history server, separately from receiving live data. When it is missing, the broker refuses the request with a status code such as Rithmic's rp_code 13 ("permission denied"), and the chart must show the interval as unavailable rather than empty.

Senzoukria · Glossary · Updated September 2026


Live, history and depth are three entitlements

An account that streams live trades can still be refused historical bars, and an account that returns historical ticks can still lack historical depth. Providers sell these separately and host them on separate servers; on Rithmic the history plant is distinct from the ticker and order plants. A successful login proves the account exists on that system and nothing about what it may download.

  • Live trades: the ticker entitlement on the plant in use.
  • Historical bars and ticks: the history entitlement, which can be enabled for one and not the other.
  • Historical depth: rarely available from brokers; heatmap history needs recorded book updates.
  • Each refusal carries a code; keep the code and the requested interval when asking the provider.

Reading a refusal

"Permission denied" at login usually means the account is unknown on that system, a different problem from a short entitlement; an unknown system is reported by a different code. The same wording on a history request means the history entitlement is not enabled for that data type. Refusals can also be intermittent: a plant under load may refuse part of a request and accept the retry. A request that is accepted but returns nothing, with no status code, usually means the archive on that system does not reach that far back or the history plant is down.

In Senzoukria

The backtest data panel reports a refused fill in these words: "The broker REFUSED the request: « permission denied » (rp_code 13). Historical bars are not enabled on this account — that is a broker entitlement, not an app setting. Historical ticks do work, and that is what the manual replay uses." On the chart, the history notice for a partial refusal says the refusals are usually intermittent, that the chart keeps running on cached and live data, and that it retries on its own; a completed attempt with no code is reported separately as an empty archive. The connection help suggests the exact question for the broker: is my login enabled for third-party API access, for which data, and under which system name?

What to do when history is refused

  • Do not change indicators first; note the symbol, expiry, session, connection status and the code.
  • Ask the provider whether historical bars and historical ticks are enabled separately on that login.
  • Use the local cache: sessions already downloaded still open, scroll and compute.
  • For backtests, consider a dedicated history source with its own licence rather than the broker's archive.

This page in other languages

Frequently asked questions

Is rp_code 13 a bug in the software?
No. It is a status returned by the broker's history server meaning permission denied for that request. The application can retry and can keep working on cached and live data, but it cannot grant the entitlement. The fix is on the account side, with the provider.
Why does my live footprint work while the backtest cannot load bars?
Because live data and history are separate entitlements. The ticker plant is streaming trades to the chart while the history plant refuses the bar request. Ask the provider to enable historical data on the login, or use a history source licensed for that purpose.
Can historical ticks work when historical bars are refused?
Yes, on some accounts. Bars and ticks can be enabled independently on the history entitlement. When ticks are available, a tick-based replay or a locally aggregated bar can substitute; when neither is, the interval must stay marked as unavailable.

Keep reading