IB API HOWTOs and Guidelines - For Beginners

Butterfly · Nov 12, 2013

Quote from crmorris:

a question for api users, especially those using the gateway instead of tws. what kind of front end do you use for your applications? excel is so easy -- gives you a lot for free. is there anything already built, anything out of the box, any simple development ideas, AND would anybody be willing to share some code or just snapshots?

thanks.

you need to build your own front end,

Excel is fine for most trading logic, but the IB API for Excel is very clumsy and prone to manipulation error

for Java, using Eclipse RCP as a Rich Client for the underlying IB API is also a very good option. This is my next project and might do a tutorial here about it.

crmorris · Nov 12, 2013

your gui is strategy dependent. do you have a working orders display window? in the window, can you manually manipulate your orders? do you have run and stop buttons? do you have specific order cancel and modify buttons?

building a generic gui to simply run an algo is easy enough. i guess i'm wondering what lengths users went to to replicate some functionality of the tws in order to make their algos more gray than black.

i run straight black box algos, but the tws coupled with my excel interface (quote page, etc.) allows me to see and INTERACT with everything that's happening in real time.

Butterfly · Nov 12, 2013

in the following Python example, we will address the OrderID variable that is needed to accumulate your trades into IB Messaging Server.

Per IB rule, you can't have 2 trade orders with the same OrderID, unless some of the attributes of the "Order" object are simple "quantity" and "price" change. Everything else can't be changed and a new trade order needs to be issued if you want to change more than the "Quantity" and "Price" attributes.

To avoid conflicting OrderID, the IB API has a function to query the IB Messaging Server and return the nextOrderID available. It is a good idea to make this variable Global in your Python code IMO, but this is debatable for some.

Here what I did to manage OrderID in IB:

Code:

from ib.opt import ibConnection, Connection, message

def handle_order_id(msg):
    global newOrderID
    newOrderID = msg.orderId

# Main code

# Create the connection to IBGW with client socket id=123
# ibConnection = Connection.create
# ibgw_conTradeChannel = ibConnection(port=4001,clientId=123)
ibgw_conTradeChannel = Connection.create(port=4001,clientId=123)
ibgw_conTradeChannel.connect()

# Handle Order ID sent by Server
ibgw_conTradeChannel.register(handle_order_id, 'NextValidId')

# Receive the new OrderID sequence from the IB Server
ibgw_conTradeChannel.reqIds(0)

# Print the new OrderID that was sent by IB
print "This is the new OrderID sent by IB Server:", newOrderID

print 'disconnected', ibgw_conTradeChannel.disconnect()

Output will be something like this:

Server Version: 59
TWS Time at connection:20131109 22:01:26 ICT

This is the new OrderID sent by IB Server: 5

Butterfly · Nov 12, 2013

now that we have addressed the simple connection and trading tasks in IB API, we can address the difficult tasks of creating complex derivatives instruments to be sent over the IB Server.

This is a great source of confusion in all IB API implementation available out there. Programmers usually have poor understanding of what market trading is or what a real trader is all about, and will often confuse "financial instruments" with the trading logic.

The TWS GUI can be intimidating, even for a knowledgeable trader. It has everything you need to be a serious market player, almost too many things since it was build for a general audience and all kind of traders in mind. Some traders are market makers and will play the book on a stock or a specific option contract. Some traders will scan pricing patterns on hundreds of stocks, and some might simply search for significant volatility spreads on thousands of Option contracts. All these different type of traders need different type of tools to trade the market, and TWS will offer a "module" for each of those trading types.

For options, there are public strategies that are "built-in" into IB and TWS. Those strategies involve several options contracts with different strikes and maturities that can be traded at once if all attributes have been properly filled. Again, this is quite easy to do when done right, and unnecessary complex when you have no clue what those instruments are or how they are built.

Those famous options public strategies are: Straddle, Straddle with Spread, CALL/PUT Backspread, CALL/PUT Bull Spread, CALL/PUT Bear Spread, Long/Short Strangle, Long/Short Guts, Call/Put Time Spread, Call/Put Ratio Vertical Spread, Long/Short Call/Put Butterfly, Long/Short Condor. I am probably forgetting a few more but I think those should cover enough for programming examples.

rwk · Nov 12, 2013

Quote from Butterfly:
. . . The following example assume that IbPy has already been installed in your Python installation. . .

I trade via TWSAPI, and I'm thinking about switching to Python for my primary language. It's my understanding that IbPy is Python 2, and I prefer to use Python 3. Can IbPy be upgraded?

Has anybody considered using Python with the ActiveX? I am also thinking of switching from Win7 to Linux. Does anybody run the ActiveX on Linux via Wine?

Butterfly · Nov 12, 2013

Quote from rwk:

I trade via TWSAPI, and I'm thinking about switching to Python for my primary language. It's my understanding that IbPy is Python 2, and I prefer to use Python 3. Can IbPy be upgraded?

Has anybody considered using Python with the ActiveX? I am also thinking of switching from Win7 to Linux. Does anybody run the ActiveX on Linux via Wine?

I know of a programmer currently doing a port of IB API to Python 3, but it's still months away before it's finish. You could use Jython 3 if there is such a thing and load the Java IB API directly into Jython.

not sure what would be the point of using Python and ActiveX, why make things more difficult when they can be simpler ?

rwk · Nov 12, 2013

Quote from Butterfly:
not sure what would be the point of using Python and ActiveX, why make things more difficult when they can be simpler ?

I'm currently using the ActiveX with Delphi 7. I previously used Ross Hemingway's IABSocket component, but I switched to the ActiveX mostly because it is supported by IB. It works well with no quality or performance issues, and I find it easy to use. It allows me to focus on trading strategy and not worry about connectivity, etc. Unfortunately, the newer versions of the API do not work correctly with D7, though it seems to work okay with Delphi 2009.

At this point I am thinking about the future, especially when I get the next detestable forced upgrade of the API. I'm using Win7 now, and I consider Win8 pretty ugly. I would like to switch to Linux, but that requires me to change programming languages and a lot of the productivity tools I am used to. I like having a choice, but I guess I'm stuck with Pascal and Windows for the foreseeable future. I'm a dinosaur from the mainframe era, and the advantages of newer technologies just don't seem worth the bother.

Butterfly · Nov 12, 2013

not sure exactly what's your point ? what's wrong with staying with Win7 ? this is an OS issue, nothing to do with API or trading logic in programming

maybe you should consider Java as your main programming source, not ActiveX or D9, these technology are old and too commingled with Win

crmorris · Nov 12, 2013

Code:
Quote from Butterfly:

in the following Python example, we will address the OrderID variable that is needed to accumulate your trades into IB Messaging Server.

Per IB rule, you can't have 2 trade orders with the same OrderID, unless some of the attributes of the "Order" object are simple "quantity" and "price" change. Everything else can't be changed and a new trade order needs to be issued if you want to change more than the "Quantity" and "Price" attributes.

To avoid conflicting OrderID, the IB API has a function to query the IB Messaging Server and return the nextOrderID available. It is a good idea to make this variable Global in your Python code IMO, but this is debatable for some.

Here what I did to manage OrderID in IB:

Code:

from ib.opt import ibConnection, Connection, message def handle_order_id(msg): global newOrderID newOrderID = msg.orderId # Main code # Create the connection to IBGW with client socket id=123 # ibConnection = Connection.create # ibgw_conTradeChannel = ibConnection(port=4001,clientId=123) ibgw_conTradeChannel = Connection.create(port=4001,clientId=123) ibgw_conTradeChannel.connect() # Handle Order ID sent by Server ibgw_conTradeChannel.register(handle_order_id, 'NextValidId') # Receive the new OrderID sequence from the IB Server ibgw_conTradeChannel.reqIds(0) # Print the new OrderID that was sent by IB print "This is the new OrderID sent by IB Server:", newOrderID print 'disconnected', ibgw_conTradeChannel.disconnect()

Output will be something like this:

you should include modify (a resubmit) and cancel examples for completeness.

crmorris · Nov 12, 2013

Quote from rwk:

I'm currently using the ActiveX with Delphi 7. I previously used Ross Hemingway's IABSocket component, but I switched to the ActiveX mostly because it is supported by IB. It works well with no quality or performance issues, and I find it easy to use. It allows me to focus on trading strategy and not worry about connectivity, etc. Unfortunately, the newer versions of the API do not work correctly with D7, though it seems to work okay with Delphi 2009.

At this point I am thinking about the future, especially when I get the next detestable forced upgrade of the API. I'm using Win7 now, and I consider Win8 pretty ugly. I would like to switch to Linux, but that requires me to change programming languages and a lot of the productivity tools I am used to. I like having a choice, but I guess I'm stuck with Pascal and Windows for the foreseeable future. I'm a dinosaur from the mainframe era, and the advantages of newer technologies just don't seem worth the bother.

i believe a lot are stuck here. things work, but aren't optimal; rebuilding is a monster project with what appears to be limited payoff.

i wasted a lot of time working with linux, sql, and the trading shim -- what seemed like a simple command line interface for ib's api -- was nearly impossible to configure and get working even building from scratch. i've contemplated python, but historical analysis can be slow and getting packages installed etc is a nightmare. i've done a lot of work with r but making r run programmatically as opposed to using vectors is a bit of a nightmare. so, we're stuck where we started. will it pay off? c++ is an option, so is c#, but productivity in the first is slow -- the second is proprietary and windows.

what's needed to get over the hump here? AND, if i'm going the c++ route, i wonder if anybody's done the real heavy lift with a c toolkit for ib's api. rudi meier built a new c++ api framwork and twstools which used xml etc to interact with ib's api, but it wasn't clear you could reliably submit, modify, cancel orders with it.

where to go ... ??