I love IB but their API sucks, you have to run TWS or the gateway with manual 2 factor login. Anyone managed to improve on that? I'd like to get account and market data from code running on the cloud.
IB's API doesn't suck, it's very low level. It's asynchronous and works in multiple languages. There are a few good R and Python wrappers that you may want to check out.
Sure, good idea, let's disable 2FA on your life savings account, just because you can't have 2 logins from different locations, or two different users.
> IB's API doesn't suck, it's very low level.
IB's "API" sucks hard, and it's not low level at all.
First, it's not a real API between you and IB's servers. It's actually an API between your software and the IB heavy, graphical, client that you installed (the API gateway just being a lightweight client). You have to start a listening local socket on the heavy client, and send your messages to it.
Which means the basis of IB automation starts with automating the start of a heavy graphical client, login with GUI input boxes, and keep the graphical client up (note that running this client will disconnect you from everywhere else, you now cannot use the IB phone app for instance).
Second, it's not a real API, it basically just allows you to send messages to the client that emulates GUI actions you would have done with your mouse. Is that what you call "low level" ?! For instance, if you want to retrieve your executions > 2 days, you have to open a specific window on TWS and _THEN_ make your API call to the client. This is INSANE.
Hell, even the documentation of their various API itself is a joke. You can find gems such as:
> gateway may sometimes need to be restarted intraday. The possibility of avoiding intraday restarts so that gateway can typically remain running all day is under review.
> It's asynchronous
It's asynchronous in the _worst_ possible way. Basically you send messages to the heavy client, asynchronously, and you have a single stream of replies all tangled together with no means to know from which request they originate, which is why all wrapper implementations just _force_ you to make synchronous API calls: so that they can match the replies to the requests.
> There are a few good R and Python wrappers
There are only some half-baked, unfinished, tutorial-driven libraries that do synchronous request-reply for 50% of the protocol. The official library being an automatically-generated python binding of the Java SDK. Not my definition of "good".
Did you actually ever used these APIs in real-life?!
You can, you just have to pay for market data for both of them: https://ibkr.info/article/1004
> First, it's not a real API between you and IB's servers.
Well it is a "real API", it's just not the one you want.
You can have the one you want but it's expensive: https://www.interactivebrokers.com/en/index.php?f=4988
> the API gateway just being a lightweight client
You talk a lot about the "heavy graphical client", seemingly ignoring the Gateway, which is the canonical way to access the API.
> Did you actually ever used these APIs in real-life?!
Not the other user but FWIW, yes, I have. They work fine.
The FIX API is different. It's just an order entry / RTD API. i.e. it's just used to send orders, and mainly targeted to companies which already use FIX e.g. because they already have other brokers. You cannot do things like retrieve your previous orders, positions, contract information, historical market data, historical funding, etc. Everything that you basically need to manage your portfolio.
> You talk a lot about the "heavy graphical client", seemingly ignoring the Gateway, which is the canonical way to access the API.
The IB gateway _is_ a graphical client too, that's part of the problem. Even though they stripped most of the windows from it, you still have to run a X server, automate the filling of input boxes for logging/password, etc, etc.
You can also restrict IP address access and lock down the server, but yes I also do not think disabling 2FA is a good idea.
> First, it's not a real API between you and IB's servers. It's actually an API between your software and the IB heavy, graphical, client that you installed (the API gateway just being a lightweight client). You have to start a listening local socket on the heavy client, and send your messages to it.
The reason it is done this way is to prevent needing to upgrade all clients when there is a "better" way to do stuff. To think that a $20B company does not have the resources to strip away the minimal windowing stuff for the gateway does not pass the smell test. There is a reason they do things this way and the main reason is that it enforces conscious decisionmaking on the part of the user:
1) Automating filling in login/password: need to decide how YOU are going to store the password securely
2) Disabling 2FA: need to decide how YOU are going to secure the server
So in my case, I decided I will leave 2FA enabled, restrict IP access to one of two IPs, and log in using 2FA once a week. Probably a global maximum in the tradeoff between convenience and security.
> It's asynchronous in the _worst_ possible way. Basically you send messages to the heavy client, asynchronously, and you have a single stream of replies all tangled together with no means to know from which request they originate, which is why all wrapper implementations just _force_ you to make synchronous API calls: so that they can match the replies to the requests.
> There are only some half-baked, unfinished, tutorial-driven libraries that do synchronous request-reply for 50% of the protocol. The official library being an automatically-generated python binding of the Java SDK. Not my definition of "good".
> Did you actually ever used these APIs in real-life?!
ib_insync works pretty well and though I have only ever used it seriously in a synchronous manner, the synchronous API is implemented on top of the asynchronous API. Check it out!
https://documentation.tradier.com/brokerage-api/trading/plac...