LessonThis is a lesson restated in new words. Any figure in it is an example from the source, not this desk's record.
A Python trading app talks to Interactive Brokers through two official roles: a client that sends requests, and a wrapper that receives callbacks. The lesson builds one class that inherits both, starts the client's run loop on a thread, and connects to the local gateway. A successful session calls a wrapper method that prints a connected line. Paper trading is enough for that test. A funded account is a separate step the lesson reserves for live orders.
Why it matters
Models and backtests stay on the machine until something can place, cancel, and account for trades. Interactive Brokers is the broker the lesson uses, chosen in the talk for a relatively low account minimum and for a Python API that followed an older Java API. The gateway is the desktop piece that lets the script reach the account. Once the connected callback fires, the same object can later request quotes, account fields, and orders. This session only proves the socket.
The idea in plain words
The API's two base classes split the conversation. The client is how Python asks for something. The wrapper is how the server answers, through methods that the library calls when a message arrives. A request goes out, the server replies, and the reply lands in a callback. That round trip is the whole shape of later features. Market data, account updates, and order entry are client calls. Their results arrive as wrapper methods.
Requests are queued. Calling a client method does not by itself flush the queue. The run method drains it and dispatches answers to the wrapper. Calling run by hand after every request would freeze the rest of the program inside that drain. The lesson starts run on its own thread as soon as the object is built, so anything placed on the queue afterward is sent while the rest of the script continues. That is the same threading idea as overlapping a wait with other work.
How to use it
Install the Python package with pip install ibapi, install the broker's gateway, and open an account. For a first connection the lesson uses the paper-trading login. In code, subclass the wrapper and the client. The lesson names the wrapper subclass as the controller and leaves its constructor empty at first. The client subclass, named as a socket, must receive a wrapper instance, because replies need a destination. Its constructor forwards that wrapper into the client base class.
A third class, the trading application, inherits the controller and the socket. Its constructor calls both base constructors and passes itself as the wrapper argument to the socket. Immediately after that, it creates a thread whose target is run and starts the thread. From then on, client requests are drained in the background.
The proof of life is a wrapper callback the lesson attaches so that a completed connection prints the word connected. The matching client call is connect. The lesson passes host 127.0.0.1, port 4002 for the default paper gateway, and client id 0. The gateway has to allow API connections. That switch sits in the gateway or trader-workstation API settings, and the same screen is where the port can be changed. With the gateway logged into paper trading, creating one trading-application object is enough. The server hits the callback and the script prints connected.
What usually goes wrong
The gateway can be installed and still refuse the socket if API access is unchecked, or if the script's port is not the port shown in the gateway. Paper port 4002 is the lesson's default. A live gateway often listens elsewhere, so a copied port number fails even when the login is valid. Client id collisions matter once a second script connects with the same id.
Forgetting the thread is a quieter failure. The object is constructed, connect is called, and the request sits in the queue because run is never looping. The connected line never appears, and the code looks idle. Starting run on the main thread instead of a worker thread has the opposite symptom: the call connects and then the script does not move on, because the drain loop does not return.
The wrapper and the client also have to be the same object graph. If the socket is built with a different wrapper from the one whose callback you edited, the server will answer a wrapper that does not contain your print. The lesson avoids that by passing self from the combined application class.
Questions people ask
Do you need a funded account to see the connected line?
The lesson says paper trading is enough to exercise the API. Funding is for live orders.
Which host and port does the lesson use?
Host 127.0.0.1, port 4002, client id 0, against the paper gateway, after API connections are enabled.
What is the thread for?
It keeps the client's run loop draining the request queue so later calls, and the rest of the program, can proceed after connect returns.