Interactive brokers native python API
Until quite currently interactive brokers failed to offer a python API for their computerized buying and selling software program.
Instead you needed to positioned up with diverse 3rd birthday celebration answers, considered one of which swigibpy I use myself. Swigibpy wrapped across the C implementation. I wrote a chain of posts on how to use it, startinghere.
Although swigiby has been very good to me its always better to use official solutions if they exist. And lo and behold after many people begging them we finally have a native python API, which was released a few weeks ago. I'll also be utilising this API in pysystemtrade when I get round to adding the 'talk to broker' part.
I've decided to reissue the same posts I wrote before to help tremendously inexperienced programmers (like myself) get up to speed with the usage of the API. The professional documentation for the API is ... Properly ... Complex ("Our API additives are aimed toward experienced professional builders inclined to enhance the modern TWS functionality. And willing to study our minds") [okay, I added the last part myself].
Because I'm lazy the posts are same, regardless of the identical bad jokes, except in which the 2 implementations vary. So if you're acquainted with my earlier collection of posts this ought to be a breeze.
(Assumptions: I am the use of Python three.5.2; older or more recent variations may also damage. I will count on you realize your manner round Python to the extent of being able to create a simple bundle and modules and run them. My command line examples may be for Linux however similar things need to be possible. Also which you recognize the dangers and risks of trading futures; however you may need to sign quite a few disclaimers earlier than IB assist you to do this for actual so I will let them worry approximately that.)
Getting a test account, downloading the IB TWS
To play with IB without signing up for real you will need a test account. By the way if you are serious and you get a real IB account you can also request an additional account for simulated trading.
(The check account is not very practical, eg costs may be overall rubbish. The simulated account is a good deal better even though for a few motive you do not constantly get L1 and L2 facts to all the statistics feeds your actual account is signed up to. If you're going to do any systematic buying and selling in the near future I pretty recommend signing up to IB and the use of a right simulated account. It would not fee whatever in case you do not change or use any additional records feeds.)
We are not going to bother downloading the TWS software, that's a as a substitute heavy front quit beneficial for trading yourself; however the a lot lighter and more strong 'Gateway'. Here is the way you do it for unix:
(I suggest you to also download the TWS API in some unspecified time in the future to have a play, however I don't advise it for everyday strolling of a strategy because it seems to be very volatile because of the extremely good lardy weight of fancy ultra bloated GUI that it has to help.)
- Go tohttps://www.interactivebrokers.com/en/?f=%2Fen%2Fcontrol%2Fsystemstandalone-ibGateway.php%3Fos%3Dunix
- Follow the instructions.
- Select IB API radio button
- Under username put 'edemo' and under password put 'demo123'.
- Click on the Configure menu. Go to API settings
- Socket port - should be 4001.
- Trusted IP addresses - should include 127.0.0.1. If it doesn't you will need to add it.
- Read only API - uncheck this here.
- Go to precautions. You might want to suppress market cap warnings here when you start trading in earnest. Make sure you know what you are doing.
- Go to presets. Again check you are happy with the limits shown.
(There is nothing special about 4001 so you can change it but be sure to remember the number and only use a radically different number if you realise you might break Linux in the process. Checkhttp://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers and make sure your game of Microsoft Ants isn't running. You could run two or more Gateways in parallel each connecting to live and test accounts; and associate a different socket (I use 4001 up to about 4005) with each account and gateway session.
127.0.0.1 is simply 'this device'. If your code is running at the equal device because the Gateway you are first-rate. Otherwise eg if you are on a community you'll ought to include the IP cope with of another machines that could connect to the Gateway.)
Downloading required python libraries
Install the python API:
http://interactivebrokers.Github.Io/#
Install the python libraries:
/IBJts/source/pythonclient $ python3 setup.Py deploy
Note: The test instances, and the documentation talk to a python package called IBApi, however the actual package is called ibapi. Go determine.
You might need to perusethe legit IB API manual.
Running the example
Run the code in this gist.
If it really works properly you have to see some thing like this:
Getting the time from the server...
1395845174
So we now seem to have obtained a very complicated manner of tellingunix time!
Also I seem to have dedicated the lethal sin of 'like right here is some code, and it seems to work' with none clarification. So lets dig into this a piece extra.
All you wanted to recognize about IB connections but frankly could not care much less
if __name__ == '__main__': ## ## Check that the port is similar to at the Gateway
### ipaddress is 127.Zero.Zero.1 if one same system, clientid is arbitrary app = TestApp("127.Zero.0.1", 4001, 10)
<snip - more code here>magnificence TestApp(TestWrapper, TestClient): def __init__(self, ipaddress, portid, clientid): TestWrapper.__init__(self) TestClient.__init__(self, wrapper=self) self.Connect(ipaddress, portid, clientid)<snip - code missing here>
(Pedantic point - Although the code says tws here, it definitely way gateway. Actually the purchaser doesn't know or care what is on the alternative end of the relationship.)
As I said above you can have any number of IB servers (gateway or TWS session) running; so you need to pass the host (just 'this machine') and port when connecting (here the function is rather dull). As briefly alluded to above each IB server will listen out for clients on a particular port (so these should be unique to the server).
You can also have numerous (32) clients connecting to the same server, each with their own clientid. For example I have one client picking up prices; another receiving accounting information, another managing orders, various one off clients getting diagnostic information and one doing the washing up.
If a clientid is already in use by means of a connected consultation then IB will cry.
Back to the tale.
magnificence TestApp(TestWrapper, TestClient): def __init__(self, ipaddress, portid, clientid): TestWrapper.__init__(self) TestClient.__init__(self, wrapper=self) self.Connect(ipaddress, portid, clientid) thread = Thread(target = self.run) thread.start() setattr(self, "_thread", thread)
<snip>
There are two parts to the IB story: a wrapper and a client. The client asks the IB server (gateway or TWS) to do stuff, and the wrapper receives the messages. The Thread bit kicks off a process inside the client which listens for messages and plumbs them into the right wrapper function. By gluing them together in the App object we can hide all this ugliness from our ultimate trading software.
Writing for the IBApi consists of writing a feature within the purchaser which asks the server to do some thing, and then writing a feature within the wrapper to address what comes back.
If that seems like Outer Mongolian to you, do not worry. You shouldn't ever want to mess with these things. The factor is once we've our purchaser object (instance of IBclient) we are able to make it do cool matters, like inform the time.
Telling the time - the tough way
We now name the speakme clock approach of the IBclient:
if __name__ == '__main__': app = TestApp("127.Zero.Zero.1", 4001, 10)
current_time = app.speaking_clock()
<snip>
self.ReqCurrentTime() is an example of a classy class EClient functions, fromthe official IB API manual. These are the functions that ask the server to think about doing something.class TestClient(EClient): """ The customer method We don't override local strategies, however as a substitute call them from our very own wrappers
"""
def __init__(self, wrapper): ## Set up with a wrapper inner
EClient.__init__(self, wrapper) def speaking_clock(self): """ Basic example to tell the time :return: unix time, as an int
"""
print("Getting the time from the server... ") ## Make an area to shop the time we are going to go back
## This is a queue
time_storage=self.Wrapper.Init_time() ## This is the local technique in EClient, asks the server to ship us the time please self.ReqCurrentTime() ## Try and get a valid time
MAX_WAIT_SECONDS = 10
strive: current_time = time_storage.Get(timeout=MAX_WAIT_SECONDS) except queue.Empty: print("Exceeded most look ahead to wrapper to respond") current_time = None
while self.wrapper.is_error(): print("Error:") print(self.get_error(timeout=5))
return current_time
Things which are interesting here #1: concurrency
The issue we have here is that the IB API is very much set up as an event driven process. So not like normal sequential code like function A calling function B and function A returning the answer back. No instead we have function A just kind of hanging around waiting for function B and then somehow by magic function B justhappens.
So what we need to do is make the consumer-server dating appear sequential, at least to something sitting out of doors the wrapper module. That additionally way we need to address the situations of the thing not completing in a reasonable time and completing with an errors.
Briefly: time_storage is a queue, that is a chunk like a listing but it works better in this form of concurrent technique. Once the queue is created the time will be brought to it. We are glad to anticipate 10 seconds for the time to arrive, but if we wait longer for this to manifest then we decide to surrender.
Warning: This form of programming in all fairness concerned. Based on my revel in over the last few years the setup above is best for buying and selling at frequencies of a few instances an afternoon, but greater common trading would likely require greater complex code which contain rewriting tremendous parts of the wrapper and the client. Alternative strategies encompass this one.
I've updated this post to include a more robust handling of concurrency. For helping me with this section I'd like to thank Ewald over at groups.io/g/twsapi/,Miguel andRyan on twitter, and David Beazley whose book I found useful. His curio project also looks interesting, although this is Unix only right now.
Things that are interesting here #2: The contents of self.wrapper
All the things we are pulling out ofself.wrapper (which is the thing that is passed in when we initialised the TestClient object) are set somewhere elseas if by magic.Actually they get set when the IB server summons the wrapper, calling the appropriate method. Inthe official IB API manual these are the very classy EWrapper Functions.
There are two simple sorts of stylish EWrapper features / methods: 'local' techniques that the server is aware of about and we override with our personal code, and new methods that we use to save, get, or take a look at information this is being handed by the server. In the primary instance here there are a gaggle of techniques to address the time, and another bunch to address errors. Lets address the errors first:
Methods that manage mistakes
class TestWrapper(EWrapper): """ The wrapper deals with the action coming back from the IB gateway or TWS instance We override methods in EWrapper that will get called when this action happens, like currentTime """
## mistakes coping with code
def init_error(self): error_queue=queue.Queue() self._my_errors = error_queue def get_error(self, timeout=5): if self.Is_error(): try:
return self._my_errors.get(timeout=timeout) except queue.Empty:
## edge case where another thread has taken the error before us
go back None return None
def is_error(self): an_error_if=not self._my_errors.Empty() return an_error_if
def mistakes(self, id, errorCode, errorString): ## Overriden approach
errormsg = "IB errors identity %d errorcode %d string %s" % (identity, errorCode, errorString) self._my_errors.Positioned(errormsg)
Note the two exceptional kinds of method; init_error, get_error, and is_error are simply my own strategies to make certain the callback has somewhere to keep the mistake and return it to the users. Wheras mistakes() is mandated via the IB API - in case you took it out or renamed it the factor would damage.
Methods that certainly do something vaguely useful like tell the time
class TestWrapper(EWrapper): """ The wrapper deals with the action coming back from the IB gateway or TWS instance We override methods in EWrapper that will get called when this action happens, like currentTime Extra methods are added as we need to store the results in this objects _my_data store These all have the form init_ or is_ """
<snip>
## Time telling code
def init_time(self): time_queue=queue.Queue() self._time_queue = time_queue return time_queue def currentTime(self, time_from_server): ## Overriden method
self._time_queue.Positioned(time_from_server)
Again there is one mandated approach (currentTime), and the opposite method is delivered to make getting the time out less difficult.
Client server interplay for dummies
So we could reiterate what occurs here.
<In the client function>
def speaking_clock(self): print("Getting the time from the server... ")
## Make an area to save the time we are going to go back
## This is a queue
time_storage=self.Wrapper.Init_time()
<in the TestWrapper class, of which the client self.wrapper is an instance>
## Time telling codedef init_time(self): time_queue=queue.Queue() self._time_queue = time_queue return time_queue
<back in the client function speaking_clock>
## This is the native technique in EClient, asks the server to send us the time please
self.ReqCurrentTime()
## Try and get a valid time
MAX_WAIT_SECONDS = 10 try: current_time = time_storage.get(timeout=MAX_WAIT_SECONDS)
<at some point in this while loop, in the TestWrapper class, of which the client self.wrapper is an instance this will get called at some point ... hopefully.... >
<and back in the client function speaking_clock, in the while loop>def currentTime(self, time_from_server): ## Overriden method
self._time_queue.Positioned(time_from_server)
strive: current_time = time_storage.Get(timeout=MAX_WAIT_SECONDS) except queue.Empty: print("Exceeded most look ahead to wrapper to respond") current_time = None
even as self.Wrapper.Is_error(): print(self.Get_error()) go back current_time
So to summarise now we set _time_queue in the wrapper to accept a value and then ask the server wrapper.reqCurrentTime(); then somewhere in the ether the TestWrapper instance method currentTime gets called by the server with the parameter time_from_server; we put this value into the queue _time_queue in the wrapper instance, and this makes the time_storage.get() work. All this assumes we don't get an error condition, and / or the server falls asleep and the process hits its MAX_WAIT_SECONDS. Pretty much everything else we do with the IB API is a variation on this particular theme so if that makes sense, you are now an expert.
(Note that the parameter names in the wrapper method function definitions don't need to match those in the manual; in the manual it uses time which is already the name of an imported module.)
And we are executed
Although this example is very simple, like the writer, it does illustrate most of the 'gotchas' from running with Python and the IB API. Subsequent posts will enlarge on this situation to cover the entire lifecycle of having a fee, producing an order, getting a fill, locating out what positions we've and running out whether or not we've got made sufficient cash to shop for a decent laptop.
This is the first in a sequence of posts. The subsequent put up is on historical records is right here.
Appendix: Some technical notes
1) The use of threading here is very basic and more experienced programmers may wish to consult theIB API forum where this topic has had much more technical discussion.
2) There is a fair better abstraction of the API (which I plan to apply myself inpysystemtrade) to permit you to cope with more than one agents. First write some accepted, non broking precise, training:
class brokerServer(object): """ Broker server classes are called by the brokers server application (eg IB Gateway) We inherit from this and then write hooks from the servers native methods into the methods in this base class All the other non native methods from the TestWrapper example could be here as well
""" def __init__(self):
setattr(self, "_my_data", dict()) def action_to_take_when_time_set(self, time_received): print("Do something with time!")class brokerClient(object): """ Broker server classes are called by the brokers server application (eg IB Gateway) We inherit from this for specific brokers and over ride the methods in the base class to ensure a consistent API """ def __init__(self): pass def speaking_clock(self): print("Method needs to be overriden to do anything interesting")Now we write dealer unique classes that inherit from these ordinary, and additionally the IBapi training:
magnificence IBServer(EWrapper, brokerServer):
def __init__(self):
brokerClient.__init__(self) ## can't use remarkable because not used in EWrapper
def currentTime(self, time_from_server): ## Overriden technique of EWrapper
## hook returned to the generic brokerClient approach
self.action_to_take_when_time_set(self, time_from_server)
class IBClient(EClient, brokerClient): """ The client method """
def __init__(self, wrapper): ## Set up with a wrapper inner
EClient.__init__(self, wrapper)
brokerClient.__init__(self) def speaking_clock(self): """
This is overriding the brokerClient method, so that it presents a consistent API
Code would be similar to the original example
"""
I may not be the usage of this structure within the rest of the instance posts to keep away from puzzling readers, but it's right here if you want.
