> 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. You c

> 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. 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 In both cases, the point is to make sure there is a human involved in how accessing the account is going to occur. This protects both IB and the client. 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!