What I need: a lightweight solution to gather depth-of-market info. (and analyze later) What I did so far: I opened an account in IB, transferred some money. Web access works, mobile access works. Problem: I cannot find any reasonable API. Let's go through this, first I go to there: https://www.interactivebrokers.com/en/index.php?f=5041 It has a table "which API technology best fits your needs", well perfect, Python is my favorite language. It recommends "IBKR API Software". But when I download it, inside a .zip file there are only some .cpp and .java files. No python as advertised. C++ version is from 2013 and has real compile errors, not just warnings. So that's a dead end. Let's go to "REST API". That would work for me too, but unfortunately it's in experimental stage and there is no access to depth of market. Finally there is "IB GATEWAY SOFTWARE". That is a huge program, the docs say: "The TWS API is an interface to IB's standalone trading applications, TWS and IB Gateway. These are both standalone, Java-based trading applications which were designed to require the use of a graphical user interface for secure user authentication. For that reason "headless" operation of either application without a GUI is not supported." Oh, it explicitly says no headless for you. OTOH the docs have an interface to query market data: http://interactivebrokers.github.io/tws-api/market_depth.html So there is no API, only a huge Java program with GUI that has API in it. Is that correct? How am I supposed to run this in the cloud? How people do this usually? Are there better solutions to stream market data?
OK here is how it goes with IB: API end user never interfaces with IB servers directly. There is a middle component to which the api connects to, either TWS or the IB Gateway. You can use either. You need to download and install the api package, it contains the compiled api and sample code for all supported languages. You need to run the tws or gateway on your local machine or on the cloud as that is where your api implementation connects to.
Hold your horses ... There are limits on the number of symbols you can subscribe to. Stocks or Futures?
This guy has been around for 10,000 years, has a quality reputation, has a couple of different *reasonably*-priced products (or will customize as desired), and ..... well shoot: https://www.tradingsoftwarelab.com/jtwsdump/ NFI, by the way...
@tommcginnis, thanks for sharing, but it's not going to suit the OP: "it is currently impossible to request tick data"
Makes me wonder why given that IB now offers historical tick data requests for quite some time. Perhaps quality reputation these days only goes thus far...I know that the IB api works requesting historical tick data, I have done so myself. It takes around 5-10 minutes to implement the additional method and callback handling.
There is no real reasonable API. Depending on your platform you'll be interfaced with their really hacky RPC system. The most straightforward implementation is their Excel implementation but then again you have to deal with a MASSIVE spreadsheet that is relatively inflexible. I got around this in Python by trying to wrap the current state of the call, etc in a series of container classes and managing state by having an event loop that runs and keeps the connection alive. It was non-trivial and I do not recommend it to anyone.
Well, that is pretty much how anyone who wants to meaningfully use the IB API has to do it. No other way around it. IB's API needs a complete refresh, throwing overboard all those poor design decisions and come up with something much simpler. a) Straight forward connection management: connect/disconnect (connection state should be managed by IB's api not by the user who wraps around it), b) simple request/reply mechanism, ideally async so the user can choose whether he wants to wait for the response or implement a continuation. c) A departure from the horrific way data is returned, such as account state, fills, positions, orders, stuff like this should be very straight forward, it is not. But I won't hold my breath. It will not happen anytime soon. In the meantime its impossible to not deal with the pitfalls for anyone who meaningfully wants to use this api.
Yeah their implementations are certainly better in languages like Java, but for any other language it falls apart quickly. It is a very, very old design reminiscent of my earlier programming years. Professionally, I regularly use protobuf to perform similar tasks in the data processing cycle. The upside of protobuf is they can hand you the proto files and you can select your language (as long as protobuf implements it) and generate completely type safe, accurate, and updatable RPC calls. It's definitely async in it's current mode but god is it awful. For handling multiple requests I had to build a super hacky queue system. Indeed. I'd probably release my stuff open source if I actually spent time cleaning it up. It would probably save people a lot of time but right now it requires my memory to use and unfortunately I can't throw that on github ;D. Yes, this is the real crime. The data returned is not only awful it's inconsistent. I've had bars get dropped, fields missing, etc. There's really no API spec, just parse-and-pray. I have an entire module filled with these inconsistencies.
For a next version I would vote for a rest api, language agnostic (I also use protobuf but json for rest would work), and they don't have to waste time on tons of language implementations.