@ymograi Thanks. In my opinion it won't matter where the access_token is generated as the login process and subsequent requests all hit the same 'kite.trade' url. On easy solution is that I change the ip of my machine and hope that it doesn't face the captcha issue. This should usually work.

While one can do that there are two issues:

a. Cloud providers generally provide ip dynamically and there is very high likelihood that my cloud machine will be reassigned the 'bad' ip again. Today after four days, my ip was caught again for captcha. I don't know whether it is a new ip which got caught or the old 'bad' ip which was reassigned again. Both of these possibilities are big problems.

b. The more important issue is that the captcha shouldn't be there. Assuming, one uses a static ip which works fine. What may happen is that one has logged in and is running a few positions. For all api interactions with kite.trade one keeps hitting the kite.trade url. Suddenly Zerodha's system decides that these requests are originating from a bot and asks for captcha "in the middle of a trading session". Once a machine is caught, that point on, all requests from that machine will be rejected for that ip. Even if one is alert and watching while it happens, one will have to atleast reboot his machine.

And this can happen to any machine, even one running on your laptop at home. Cloud machines are higher risk as they are actually running trading bots and they come from high risk sources, i.e. cloud and their requests to kite.trade would possess corresponding signatures.

While (a) part of the problem is solvable but (b) can suddenly wreck the trading session and is "open". Thats what is worrying me. I dont want to trade with such high uncertainties.