Add Continuous Futures Historical Data Support to Retrieve Bars

The ProjectX retrieveBars API currently requires a specific contract ID, such as CON.F.US.EP.U26 (ESU6), when retrieving historical candles. This works well for the currently active contract, but creates a significant limitation when building applications that require longer historical datasets.

Feature request:
Allow retrieveBars to accept the underlying/root symbol (for example, ES, NQ, MES, etc.) and return a continuous, properly stitched historical futures series across contract expirations.

For example, instead of an application having to request:

ESU6 → ESZ6 → ESH7 → ...

the application should be able to request:

ES

and retrieve a continuous historical candle series for the requested date range.

The continuous series should automatically transition between contracts according to the appropriate front-month/roll methodology. Topstep already identifies the front month automatically based on trading volume, so a similar mechanism could be used when constructing the historical series.

This is especially important for developers building custom applications around TopstepX/ProjectX. The current contract-specific approach makes it difficult to obtain a reliable long-term historical dataset because applications must independently discover contract expirations, retrieve each contract's candles, determine the appropriate rollover point, and stitch the contracts together.

More importantly, simply concatenating individual contracts can introduce artificial price discontinuities at rollover. A properly maintained continuous historical series would provide much more reliable data for:

• Charting and technical analysis

• Backtesting trading strategies

• Indicator calculations over long lookback periods

• Machine-learning and statistical models

• Market research and analytics

• Custom trading applications

• Comparing current price action with historical market conditions

The current retrieveBars endpoint also limits each request to 20,000 bars, so the ideal implementation would allow users to request an underlying symbol and paginate backward/forward through the available continuous historical data as needed.

For example:

POST /api/History/retrieveBars { "symbol": "ES", "startTime": "...", "endTime": "...", "unit": 2, "unitNumber": 1, "limit": 20000 } 

The API would internally resolve the appropriate historical contracts and return a continuous series.

If maintaining a fully adjusted series is not desirable, another useful option would be to return the unadjusted historical candles while providing the contract boundaries/roll information so that the application can construct its own continuous series.

Why this matters:
For developers building custom applications, reliable historical data is just as important as real-time market data. Without a consistent historical series, applications can produce incorrect charts, indicators, backtests, and strategy signals around contract rollovers.

Providing an official continuous futures history at the API level would significantly reduce complexity for developers and make the TopstepX/ProjectX API much more useful for serious custom trading applications.