LessonThis is a lesson restated in new words. Any figure in it is an example from the source, not this desk's record.
Historical bars for a backtest have to come from a source your code can ask. The lecture walks through Interactive Brokers: open a paper-trading session of Trader Workstation, allow socket clients, then have Python request one year of daily US stock bars and write a CSV. The account, the port, and the callback are the parts people skip.
Why it matters
A strategy test is only as honest as the prices inside it. Before any signal, you need a repeatable pull: which contract, which end time, how far back, and which bar size. The lecture's path is the broker's own API, aimed at US equities.
Two gates are stated. Market-data add-ons for this request are described as only a couple of dollars, and the account has to keep at least $500 of equity. The market-data page groups several packages, including top-of-book quotes, depth, indices, and bonds. The demonstration uses US stocks.
The idea in plain words
Trader Workstation sits between your script and the broker. Install it and log into paper trading. That login is a simulated account, not a live brokerage session. Open the settings wheel, then the API page. Enable socket clients so a local program may connect. Leave the API read-only if you only want data. Turn that lock off only if the same session will also send orders. On this paper setup the socket port defaults to 7497.
The Python side uses the ibapi package plus pandas. One class inherits both EClient and EWrapper. The client sends requests. The wrapper receives answers. The constructor points the client at that same object, starts an empty list for bars, and sets a finished flag to false.
Bars do not come back as a return value. A historical-data callback receives a request id and a bar. Append the bar's date, open, high, low, close, and volume. A second callback, fired when the request is done, sets the finished flag. A function that calls app.run is the target of a background thread, so the script can keep working while messages arrive.
How to use it
Connect to 127.0.0.1 on port 7497 with a client id. The lecture uses 123, and notes that a master id can be set if several apps attach. Start the thread and pause about a second.
Build a contract: symbol, security type stock, exchange SMART, currency USD. The function defaults the symbol to Nvidia. The run shown requests Apple. Set the end time to now. Ask for one year of one-day trade bars, regular hours, dates as strings, no live updates, and an empty list of chart options. Rate limits exist, so the bar size is not free.
Sleep half a second until the finished flag flips, then disconnect. Build a dataframe, add the percent change of the close, drop the empty first return, and write stock_data.csv with the date, the four prices, volume, and that return.
What usually goes wrong
The lecture's debug pass hit two code mistakes. Column selection used parentheses, so pandas treated the names as a function. Brackets select columns. The currency was written like a ticker suffix. The contract field is currency.
Paper and live sessions do not share every default. A script pointed at the wrong port waits forever, because the end callback never arrives. The lecture's paper port is 7497.
Asking for more history, or a finer bar, than the rate limit will serve is the third miss. Check the row count against a one-year daily request before you trust the file.
Questions people ask
Which port does the paper session use?
In these settings the paper-trading socket defaults to 7497. The script connects to localhost on that port. The example client id is 123.
Where do the bars show up in code?
Not as the return value of the request. Each bar arrives in the historical-data callback. The end callback flips the finished flag.
What did the sample request pull?
One year of daily trade bars for Apple, regular hours, ending when the script ran, saved with open, high, low, close, volume, and a close-to-close return.