I¡¯m a bit unclear about the situation here. In the subject, you mention ¡®too many missed authentication attempts¡¯, but you don¡¯t explain what you mean by this in the message.
?
If you keep trying and failing to login to TWS/Gateway, eventually a dialog will pop up with a message like this: ¡°Too many failed login attempts. Please wait 4 minutes & 47 seconds before attempting to re-login again.¡±. ?This situation can occur if you¡¯re handling 2FA via IBC and IBKR Mobile app, and IBC deals with it automatically. Note that during the specified wait, TWS/Gateway is just sitting there with the login dialog on display, waiting for the next login attempt to be initiated, which IBC does after the specified delay. So during this period, if the API client program tries to connect, it will fail because it won¡¯t accept API connections until login is completed successfully (obviously).
?
Even if you¡¯re not doing 2FA, just repeatedly starting TWS/Gateway, logging in successfully, and then restarting after a short time, I suppose it¡¯s possible that IB might put up the ¡°Too many failed login attempts¡±, because they might reasonably think that something fishy is going on, though if the logins are successful I don¡¯t really see why they should complain.
?
Could this be your situation? If so, then you should consider modifying your API client so that if connection fails, it attempts again after a suitable delay. All my API clients are configured to do this (this means I can start them at any time and it doesn¡¯t matter If TWS/Gateway isn¡¯t running at the time:when it is started later, they will soon connect again and succeed.
?
If not, then I don¡¯t know what to suggest. I¡¯ve certainly never seen anything to suggest that IB will ever block API connections after a successful login. In fact I think API connections are purely local to TWS/Gateway, in the sense that the IB servers seem to have no knowledge of them: TWS/Gateway acts as a proxy for them in everything they do.
?
Come to think of it, the scenario described above would account for the fact that it works when you run manually: in this case, your Docker instance is sitting waiting for the next login attempt after the requested delay, your API client has failed to connect because login hasn¡¯t completed, but when you start a new instance manually login succeeds immediately, so the API client can now connect.
?
I hope all this makes sense!
?
Richard
