[GUIDE] How to Overcome the new API Changes to Refresh/IP Throttle after 10 tries

[SRvSaha]

[UPDATE] Issue Resolved in v5.2.0 Release

Don't Bombard CoWIN Servers with huge number of requests, if you are using the App, in that way you might be in trouble. In case you are using it, use with precaution. You may get idea of openings of slots from historical data available here: https://under45.in/reports.php or from some alerts/notifications like Telegram or by running this App (unless you are bombarding with 1/2 hours of searching for slots). Lately, found that this service http://vaccineslot.in/ provides very good data analytics of Slots in Across India in every district/state.

Reference Suggestion: https://github.com/bombardier-gif/covid-vaccine-booking/issues/489#issuecomment-857032762

Due to some new changes in the CoWIN APIs there has been the following observations:

1. Seems like they removed Captcha requirement for Booking
2. They have added some hard refresh limit of the APIs so that users can't keep on hitting their server. Currently, based on User Inputs and analysis, it has been found that the Limit is of 10/20 Requests after which IP is throttled. {'message': 'User is not authorized to access this resource with an explicit deny'}

So, a temporary workaround to go around this for the moment till we get a solution is this:

This is a two step Process: FindingSlot and BookingSlot.

Step For Finding Slot:

• Run the Application as usual (CoWinVaccineSlotFinder.exe for Windows, or run.sh for Linux/Mac) and then after you receive the OTP and enter the OTP, you'll be shown that your OTP is stored in authToken.json file. Once that is done, close the application.

• There is an option in the config file appsettings.json "ProtectedAPI": { "IsToBeUsed": true CHANGE it to "IsToBeUsed": false This would make use of the Public API to find the Slots for the meantime, since there is no hard limit of 10/20 requests. It'll work till 100 requests/5 minutes.

• After making the change in the Config, save it and Run the Application (CoWinVaccineSlotFinder.exe for Windows, or run.sh for Linux/Mac) and let it run until it finds a slot. Proof below that it runs even after 10 tries as well.

• After the Application starts running, again go to the config file and CHANGE it to "IsToBeUsed": true . We are doing this because for Booking of Slot we need the Protected API and we don't want to waste any time when slot is found

• Following will be shown when you run the Application as it will keep on searching and when Slot is found it'll crash the application as booking is not allowed using Public API. You just need to close the Application and following the next step for booking.

Step For Booking Slot

• As soon as you find slot is available from the above step, close the Running Application as the Application will automatically crash.

• Make sure "ProtectedAPI": { "IsToBeUsed": true is set in the config file appsettings.json

• Run the Application once again (CoWinVaccineSlotFinder.exe for Windows, or run.sh for Linux/Mac)

• This will not need the OTP again as your OTP is already being asked in the above step and your authentication credentials are saved in authToken.json.

• You'll right away see the slot and your booking will be done. Since Captcha is still not removed from Code, so use "AutoReadCaptcha": true

This is just a hot-fix without making any changes in the Code. Please do let us know if this trick works so that we can work on fixing it and releasing a new release version.

[SRvSaha]

@SRvSaha boss i m facing 2 issues-

1. When i changed public api to find by pin and find by district then error shown as per screenshot attahced.

2. When i changed it back to calendar by pin and district then though it was searching for slots but even i set my refresh limit to 3000 millisecods. It started giving me fatel error even on public api and even after restarting the application fatel errror did not stopped

Ok @520rahul I will check it out. I got the reason why it is failing. Basically structures of the APIs are not same I will have to test it myself. Meanwhile just check with the description of the Issue to see that flow works.

[520rahul]

@SRvSaha this error is coming after changing public api to find by pin. Though session is not expired still it is showing this

[SRvSaha]

@govindasomani @Tnu02 @520rahul @Suren1978 At the time of Testing, please change the URLs to use findByPIN and findByDistrict as well. Based on user feedback from multiple places, people are telling that findByDistrict usually is used in Telegram as it has near real-time data and doesn't cache.

I am adding the block here: "FetchCalenderByDistrictUrl": "https://cdn-api.co-vin.in/api/v2/appointment/sessions/public/findByDistrict", "FetchCalenderByPINUrl": "https://cdn-api.co-vin.in/api/v2/appointment/sessions/public/findByPin"

@520rahul @govindasomani @Tnu02 @govindasomani @Suren1978 Guys, sorry you won't be able to test the findBy APIs. There are some difference in the response structure of calenderAPIs and findAPIs.

So, ignore the testing of findAPIs. Just do the testing as per the Issue description in Peak Hours in Live Scenario. Need changes in Code for intergation of findAPIs

Thanks @520rahul for pointing it out

[SRvSaha]

Also, a request to all those who haven't starred the Repo. Please give it a star so that it will be easily available in Github Search and together we can help out to more people!

P.S: I don't get any benefit for having more Stars, it's just for the community to reach out to more people.

[govindasomani]

@Tnu02 @520rahul @Suren1978 @govindasomani Guys need your feedback on the following:

1. Is the current description working? We need to test it and then I will make changes and release v5.1.1 where these things will be taken case automatically.
2. What I am planning to do is: By Default after OTP verification all searching will be based on Public APIs and then Booking will be tried using Protected APIs

The description is perfect. Need to test it in a live environment when slots are releasing. Conceptually though, there seems to be no problem with the flow.

Agree with @govindasomani

@govindasomani @Tnu02 @520rahul @Suren1978 Okay cool. Let's wait till tomorrow 8 pm, since most bookings come from 4pm to 8 pm. See if you can do the testing and tally the results will Telegram/other realtime notifiers if we are getting the slots in correct time. And then is booking successful. If these things are okay, I will make the changes and release by EOD around 11 pm when traffic is low. Your support and comment please?

Sure. Will keep you posted on the experience.

@SRvSaha Just tried in a couple of locations. The public API did not detect the slots till much later, even though the telegram notifications had come for the same location. By the time I changed to protected API basis the telegram notification, the slots were booked. Will continue testing for a few more locations where I know the timing of release and revert if this pattern continues.

[SRvSaha]

@govindasomani Thanks for the feedback. Yeah, I guess Telegram Alerts are based on findByDistrict API. As per many threads, that has near real-time data. Unfortunately, due to different structure of API response for findAPIs wrt calenderAPIs, we won't be able to port it as is. Need changes.

Just a suggestion, keep your session logged in by following Step 1. As soon as Telegram notifies, run with the ProtectedAPI right way. See if you can get the slot then.

[SRvSaha]

@govindasomani @520rahul @Tnu02 @Suren1978 I see a flaw in the Process. Let's say, we are able to identify that slots are available using Telegram Notifications or Public API (findByAPIs after integration). Even after that, there may be let's say 3 Centres where slots are available. And assume each center has 4 slots. So overall there are 12 booking attempts we need to make. However, since we would need the ProtectedAPI where refresh limit is 10, we will get stuck up after the 10th Request if we aren't lucky enough to get the slot booked in the first 10 attempts. That's a gamble. How do we go about that? Any thoughts?

So far I saw in discussion threads, basically after 10/20 attempts, CoWIN Portal forcefully logouts the account. Now, the interesting part of the puzzle is, will they allow a new OTP if say I get blocked after 10 attempts. If they are allowing then, we can handle the scenario by regeneration of OTP, validating it and then proceeding as usual like we do in case of Session Timeout in case of Booking or say Searching. That logic is fine. Only thing to research about is, whether they are issuing OTPs or not. I feel that they might issue the OTP since we will login only once with OTP and then rest of the things will be done using Public APIs. Not sure though. See if you can find any proofs or this.

[govindasomani]

@govindasomani @520rahul @Tnu02 @Suren1978 I see a flaw in the Process. Let's say, we are able to identify that slots are available using Telegram Notifications or Public API (findByAPIs after integration). Even after that, there may be let's say 3 Centres where slots are available. And assume each center has 4 slots. So overall there are 12 booking attempts we need to make. However, since we would need the ProtectedAPI where refresh limit is 10, we will get stuck up after the 10th Request if we aren't lucky enough to get the slot booked in the first 10 attempts. That's a gamble. How do we go about that? Any thoughts?

So far I saw in discussion threads, basically after 10/20 attempts, CoWIN Portal forcefully logouts the account. Now, the interesting part of the puzzle is, will they allow a new OTP if say I get blocked after 10 attempts. If they are allowing then, we can handle the scenario by regeneration of OTP, validating it and then proceeding as usual like we do in case of Session Timeout in case of Booking or say Searching. That logic is fine. Only thing to research about is, whether they are issuing OTPs or not. I feel that they might issue the OTP since we will login only once with OTP and then rest of the things will be done using Public APIs. Not sure though. See if you can find any proofs or this.

They are allowing renewed OTP after 3 mins from previous one. So effectively, you will have to keep a higher refresh rate to avoid getting blocked within 3 minutes.

[SRvSaha]

@govindasomani @520rahul @Tnu02 @Suren1978 I see a flaw in the Process. Let's say, we are able to identify that slots are available using Telegram Notifications or Public API (findByAPIs after integration). Even after that, there may be let's say 3 Centres where slots are available. And assume each center has 4 slots. So overall there are 12 booking attempts we need to make. However, since we would need the ProtectedAPI where refresh limit is 10, we will get stuck up after the 10th Request if we aren't lucky enough to get the slot booked in the first 10 attempts. That's a gamble. How do we go about that? Any thoughts? So far I saw in discussion threads, basically after 10/20 attempts, CoWIN Portal forcefully logouts the account. Now, the interesting part of the puzzle is, will they allow a new OTP if say I get blocked after 10 attempts. If they are allowing then, we can handle the scenario by regeneration of OTP, validating it and then proceeding as usual like we do in case of Session Timeout in case of Booking or say Searching. That logic is fine. Only thing to research about is, whether they are issuing OTPs or not. I feel that they might issue the OTP since we will login only once with OTP and then rest of the things will be done using Public APIs. Not sure though. See if you can find any proofs or this.

They are allowing renewed OTP after 3 mins from previous one. So effectively, you will have to keep a higher refresh rate to avoid getting blocked within 3 minutes.

Please tally the Notifications of slot availability from these Telegram channels. They are usind findAPIs. https://covialerts.in/ (Claims faster than U45) https://under45.in/

@govindasomani @Tnu02 @520rahul @Suren1978

[520rahul]

@SRvSaha brother i was wondering if is this possible that u make 2 exe files one operates on public api and other one on protected. The exe of public api wil run continuously and will find out the slots. And on the other hand we will be logging in every 15 min in protected api exe but call will be only made after we hit enter/manual cal, not automatic cal with 15 min token expiry warning. Do u think this kind of repo possible.

[govindasomani]

@govindasomani @520rahul @Tnu02 @Suren1978 I see a flaw in the Process. Let's say, we are able to identify that slots are available using Telegram Notifications or Public API (findByAPIs after integration). Even after that, there may be let's say 3 Centres where slots are available. And assume each center has 4 slots. So overall there are 12 booking attempts we need to make. However, since we would need the ProtectedAPI where refresh limit is 10, we will get stuck up after the 10th Request if we aren't lucky enough to get the slot booked in the first 10 attempts. That's a gamble. How do we go about that? Any thoughts? So far I saw in discussion threads, basically after 10/20 attempts, CoWIN Portal forcefully logouts the account. Now, the interesting part of the puzzle is, will they allow a new OTP if say I get blocked after 10 attempts. If they are allowing then, we can handle the scenario by regeneration of OTP, validating it and then proceeding as usual like we do in case of Session Timeout in case of Booking or say Searching. That logic is fine. Only thing to research about is, whether they are issuing OTPs or not. I feel that they might issue the OTP since we will login only once with OTP and then rest of the things will be done using Public APIs. Not sure though. See if you can find any proofs or this.

They are allowing renewed OTP after 3 mins from previous one. So effectively, you will have to keep a higher refresh rate to avoid getting blocked within 3 minutes.

Please tally the Notifications of slot availability from these Telegram channels. They are usind findAPIs. https://covialerts.in/ (Claims faster than U45) https://under45.in/

@govindasomani @Tnu02 @520rahul @Suren1978

Just booked a slot basis U45 notification... the public API did not detect it at all even after the booking. I switched to true immediately on seeing U45's msg, and got hit on the 1st refresh.

[deepgandhi]

I have tried this method, but due to difference between data of protected api and public api, when I use public api for finding center it shows "XYZ" center, but when I tries to use protected api for booking it does not shows "XYZ" center at all. I am able to book 2 times but it was different centers and due to sher luck. If I had searched for specific pincode or center I will not be able to book as per this method.

[Tnu02]

I also tried checking with IsToBeUsed": false and it just keep on searching thou the slots are available, and as soon as i closed and changed it to true, slot got booked.

One more thing i have noticed is that slot are showing via exe but not on the cowin website (got notification thru U45) but how come it was not visible on the website and later showed as booked. I checked with mobile and exe.

[Suren1978]

@govindasomani @520rahul @Tnu02 @Suren1978 I see a flaw in the Process. Let's say, we are able to identify that slots are available using Telegram Notifications or Public API (findByAPIs after integration). Even after that, there may be let's say 3 Centres where slots are available. And assume each center has 4 slots. So overall there are 12 booking attempts we need to make. However, since we would need the ProtectedAPI where refresh limit is 10, we will get stuck up after the 10th Request if we aren't lucky enough to get the slot booked in the first 10 attempts. That's a gamble. How do we go about that? Any thoughts? So far I saw in discussion threads, basically after 10/20 attempts, CoWIN Portal forcefully logouts the account. Now, the interesting part of the puzzle is, will they allow a new OTP if say I get blocked after 10 attempts. If they are allowing then, we can handle the scenario by regeneration of OTP, validating it and then proceeding as usual like we do in case of Session Timeout in case of Booking or say Searching. That logic is fine. Only thing to research about is, whether they are issuing OTPs or not. I feel that they might issue the OTP since we will login only once with OTP and then rest of the things will be done using Public APIs. Not sure though. See if you can find any proofs or this.

They are allowing renewed OTP after 3 mins from previous one. So effectively, you will have to keep a higher refresh rate to avoid getting blocked within 3 minutes.

Bro i dont think so ...once i entered OTP and exhausted with 10 tries...i just delete the authToken file and immediately re run the exe..it is asking for OTP again and gives 10 tries again ....this repeated process i tried for five six times and it worked...but we have to enter OTP again n again to get 10 tries....this all process i done on same IP

[Suren1978]

@govindasomani @520rahul @Tnu02 @Suren1978 I see a flaw in the Process. Let's say, we are able to identify that slots are available using Telegram Notifications or Public API (findByAPIs after integration). Even after that, there may be let's say 3 Centres where slots are available. And assume each center has 4 slots. So overall there are 12 booking attempts we need to make. However, since we would need the ProtectedAPI where refresh limit is 10, we will get stuck up after the 10th Request if we aren't lucky enough to get the slot booked in the first 10 attempts. That's a gamble. How do we go about that? Any thoughts? So far I saw in discussion threads, basically after 10/20 attempts, CoWIN Portal forcefully logouts the account. Now, the interesting part of the puzzle is, will they allow a new OTP if say I get blocked after 10 attempts. If they are allowing then, we can handle the scenario by regeneration of OTP, validating it and then proceeding as usual like we do in case of Session Timeout in case of Booking or say Searching. That logic is fine. Only thing to research about is, whether they are issuing OTPs or not. I feel that they might issue the OTP since we will login only once with OTP and then rest of the things will be done using Public APIs. Not sure though. See if you can find any proofs or this.

They are allowing renewed OTP after 3 mins from previous one. So effectively, you will have to keep a higher refresh rate to avoid getting blocked within 3 minutes.

Bro i dont think so ...once i entered OTP and exhausted with 10 tries...i just delete the authToken file and immediately re run the exe..it is asking for OTP again and gives 10 tries again ....this repeated process i tried for five six times and it worked...but we have to enter OTP again n again to get 10 tries....this all process i done on same IP

I think if this process can be automate in application then it will work fine.....only hurdle is we have to enter OTP again n again

[Suren1978]

https://quickslot.in/

this is a cowin watcher app and this link helps to find the slot availability other than telegram....you just run n forget.... it automatically refresh and gives alert for slot availability ....just run on side window and as soon as an alert knocks just try our exe

[520rahul]

I just confirmed the limits, the whole cowin system is changed. Now, one can have only a maximum of 20 requests per session, if one goes more than that which means if one makes 20 requests in a row one will be logged out. Besides this, there's an overall boundation of 100 requests per 5 mins. So, which means if one re-login and make more than 20 requests and one repeat this thing within 5mins (20*5) = 100 requests in 5 mins (with the same IP) One will be blocked again

[betagoyal]

Don't try for slot searching, try for booking only. I am not a technical person . It might work .

[520rahul]

@SRvSaha in my opinion if u make changes in exe and after login make it optional to search for slot on manual basis (like hitting enter whenever slot comes by getting notification on telegtam) insteqd of automatic basis that would may work

[Tnu02]

@SRvSaha in my opinion if u make changes in exe and after login make it optional to search for slot on manual basis (like hitting enter whenever slot comes by getting notification on telegtam) insteqd of automatic basis that would may work

Yup.. that would be a nice editionto the exe, guess i already asked for same previously :D

[Suren1978]

I just confirmed the limits, the whole cowin system is changed. Now, one can have only a maximum of 20 requests per session, if one goes more than that which means if one makes 20 requests in a row one will be logged out. Besides this, there's an overall boundation of 100 requests per 5 mins. So, which means if one re-login and make more than 20 requests and one repeat this thing within 5mins (20*5) = 100 requests in 5 mins (with the same IP) One will be blocked again

You can use VPN to change IPs frequently ....but to get 10 tries again n again you have to enter OTP again n again ...if his is automated and as @520rahul said make it optional to search for slot on manual basis ...it will be more helpful to book slots

[Suren1978]

@govindasomani @520rahul @Tnu02 @Suren1978 I see a flaw in the Process. Let's say, we are able to identify that slots are available using Telegram Notifications or Public API (findByAPIs after integration). Even after that, there may be let's say 3 Centres where slots are available. And assume each center has 4 slots. So overall there are 12 booking attempts we need to make. However, since we would need the ProtectedAPI where refresh limit is 10, we will get stuck up after the 10th Request if we aren't lucky enough to get the slot booked in the first 10 attempts. That's a gamble. How do we go about that? Any thoughts? So far I saw in discussion threads, basically after 10/20 attempts, CoWIN Portal forcefully logouts the account. Now, the interesting part of the puzzle is, will they allow a new OTP if say I get blocked after 10 attempts. If they are allowing then, we can handle the scenario by regeneration of OTP, validating it and then proceeding as usual like we do in case of Session Timeout in case of Booking or say Searching. That logic is fine. Only thing to research about is, whether they are issuing OTPs or not. I feel that they might issue the OTP since we will login only once with OTP and then rest of the things will be done using Public APIs. Not sure though. See if you can find any proofs or this.

They are allowing renewed OTP after 3 mins from previous one. So effectively, you will have to keep a higher refresh rate to avoid getting blocked within 3 minutes.

Bro i dont think so ...once i entered OTP and exhausted with 10 tries...i just delete the authToken file and immediately re run the exe..it is asking for OTP again and gives 10 tries again ....this repeated process i tried for five six times and it worked...but we have to enter OTP again n again to get 10 tries....this all process i done on same IP

There is noissue of same IP .....I have tried more then 10 times with different OTPs after deleting authToken file ...it is working fine and given 10 tries each time

[SRvSaha]

@SRvSaha brother i was wondering if is this possible that u make 2 exe files one operates on public api and other one on protected. The exe of public api wil run continuously and will find out the slots. And on the other hand we will be logging in every 15 min in protected api exe but call will be only made after we hit enter/manual cal, not automatic cal with 15 min token expiry warning. Do u think this kind of repo possible.

Hi @520rahul, the point you have raised is valid. I am trying to automate the part that you have mentioned from the same Application. Planning to switch between find* APIs of Protected and Public as per the Rate Limit and Refresh Rate. Thanks for your feedback.

[SRvSaha]

@govindasomani @520rahul @Tnu02 @Suren1978 I see a flaw in the Process. Let's say, we are able to identify that slots are available using Telegram Notifications or Public API (findByAPIs after integration). Even after that, there may be let's say 3 Centres where slots are available. And assume each center has 4 slots. So overall there are 12 booking attempts we need to make. However, since we would need the ProtectedAPI where refresh limit is 10, we will get stuck up after the 10th Request if we aren't lucky enough to get the slot booked in the first 10 attempts. That's a gamble. How do we go about that? Any thoughts? So far I saw in discussion threads, basically after 10/20 attempts, CoWIN Portal forcefully logouts the account. Now, the interesting part of the puzzle is, will they allow a new OTP if say I get blocked after 10 attempts. If they are allowing then, we can handle the scenario by regeneration of OTP, validating it and then proceeding as usual like we do in case of Session Timeout in case of Booking or say Searching. That logic is fine. Only thing to research about is, whether they are issuing OTPs or not. I feel that they might issue the OTP since we will login only once with OTP and then rest of the things will be done using Public APIs. Not sure though. See if you can find any proofs or this.

They are allowing renewed OTP after 3 mins from previous one. So effectively, you will have to keep a higher refresh rate to avoid getting blocked within 3 minutes.

Please tally the Notifications of slot availability from these Telegram channels. They are usind findAPIs. https://covialerts.in/ (Claims faster than U45) https://under45.in/ @govindasomani @Tnu02 @520rahul @Suren1978

Just booked a slot basis U45 notification... the public API did not detect it at all even after the booking. I switched to true immediately on seeing U45's msg, and got hit on the 1st refresh.

Yes, got it @govindasomani Actually after lots of research figured out that they are using find APIs. Our by default calender APIs won't work due to caching. So I will fix this to let it work using Protected APIs if Possible. When it breaks, we will switch to public find API. In that way we will circumvent the issue. Only problem will be that we are going to be searching only for the next day. Glad that you could still book.

[SRvSaha]

I have tried this method, but due to difference between data of protected api and public api, when I use public api for finding center it shows "XYZ" center, but when I tries to use protected api for booking it does not shows "XYZ" center at all. I am able to book 2 times but it was different centers and due to sher luck. If I had searched for specific pincode or center I will not be able to book as per this method.

Yes @deepgandhi the Public and Private Calender APIs have the issue with caching, we'll shift to find* APIs

[SRvSaha]

I also tried checking with IsToBeUsed": false and it just keep on searching thou the slots are available, and as soon as i closed and changed it to true, slot got booked.

One more thing i have noticed is that slot are showing via exe but not on the cowin website (got notification thru U45) but how come it was not visible on the website and later showed as booked. I checked with mobile and exe.

Actually there may be some difference in timing of showing the slots in website vs our app. Because we don't need to deal with lots of UI jargon, we're lightweight hence whenever slots come, we'll get it faster. Now coming to the point that U45 got early notification, I am guessing the reason being usage of find* APIs. As per the community concurrent, those have either no or very minimum caching level.

[deepgandhi]

Can you explain find* API @SRvSaha ?

[SRvSaha]

find* APIs: findByDistrict, findByPIN @deepgandhi

[SRvSaha]

@govindasomani @520rahul @Tnu02 @Suren1978 I see a flaw in the Process. Let's say, we are able to identify that slots are available using Telegram Notifications or Public API (findByAPIs after integration). Even after that, there may be let's say 3 Centres where slots are available. And assume each center has 4 slots. So overall there are 12 booking attempts we need to make. However, since we would need the ProtectedAPI where refresh limit is 10, we will get stuck up after the 10th Request if we aren't lucky enough to get the slot booked in the first 10 attempts. That's a gamble. How do we go about that? Any thoughts? So far I saw in discussion threads, basically after 10/20 attempts, CoWIN Portal forcefully logouts the account. Now, the interesting part of the puzzle is, will they allow a new OTP if say I get blocked after 10 attempts. If they are allowing then, we can handle the scenario by regeneration of OTP, validating it and then proceeding as usual like we do in case of Session Timeout in case of Booking or say Searching. That logic is fine. Only thing to research about is, whether they are issuing OTPs or not. I feel that they might issue the OTP since we will login only once with OTP and then rest of the things will be done using Public APIs. Not sure though. See if you can find any proofs or this.

They are allowing renewed OTP after 3 mins from previous one. So effectively, you will have to keep a higher refresh rate to avoid getting blocked within 3 minutes.

Bro i dont think so ...once i entered OTP and exhausted with 10 tries...i just delete the authToken file and immediately re run the exe..it is asking for OTP again and gives 10 tries again ....this repeated process i tried for five six times and it worked...but we have to enter OTP again n again to get 10 tries....this all process i done on same IP

True, even I experienced the same. The OTP they send has validity of 3 minutes but usually you can get OTP before that as well. Also, yeah the issue of deleting and re-entering is tedious. We'll try to fix this.

[SRvSaha]

@govindasomani @520rahul @Tnu02 @Suren1978 I see a flaw in the Process. Let's say, we are able to identify that slots are available using Telegram Notifications or Public API (findByAPIs after integration). Even after that, there may be let's say 3 Centres where slots are available. And assume each center has 4 slots. So overall there are 12 booking attempts we need to make. However, since we would need the ProtectedAPI where refresh limit is 10, we will get stuck up after the 10th Request if we aren't lucky enough to get the slot booked in the first 10 attempts. That's a gamble. How do we go about that? Any thoughts? So far I saw in discussion threads, basically after 10/20 attempts, CoWIN Portal forcefully logouts the account. Now, the interesting part of the puzzle is, will they allow a new OTP if say I get blocked after 10 attempts. If they are allowing then, we can handle the scenario by regeneration of OTP, validating it and then proceeding as usual like we do in case of Session Timeout in case of Booking or say Searching. That logic is fine. Only thing to research about is, whether they are issuing OTPs or not. I feel that they might issue the OTP since we will login only once with OTP and then rest of the things will be done using Public APIs. Not sure though. See if you can find any proofs or this.

They are allowing renewed OTP after 3 mins from previous one. So effectively, you will have to keep a higher refresh rate to avoid getting blocked within 3 minutes.

Bro i dont think so ...once i entered OTP and exhausted with 10 tries...i just delete the authToken file and immediately re run the exe..it is asking for OTP again and gives 10 tries again ....this repeated process i tried for five six times and it worked...but we have to enter OTP again n again to get 10 tries....this all process i done on same IP

I think if this process can be automate in application then it will work fine.....only hurdle is we have to enter OTP again n again

There is a chance that they might blacklist your number if so frequently OTPs are requested. Haven't see this happening but might happen. We'll keep the Automation part for v5.2.0, as of now we need to focus on fixing the existing issue to overcome the hard refresh limit.

[deepgandhi]

@SRvSaha I have already tried it, actually before using your application I has made a Python script, bare minimum. I was using find* API. But I too faced the same issue of request limits.

[SRvSaha]

@SRvSaha I have already tried it, actually before using your application I has made a Python script, bare minimum. I was using find* API. But I too faced the same issue of request limits.

The request limits of 100 requests/5 mins will still be there. The hard limit of 10 requests is the main concern here which should get solved. Are you saying it has the hard limit of 10 requests as in the calendar APIs as well ? can you please check by running your script now @deepgandhi

[SRvSaha]

I just confirmed the limits, the whole cowin system is changed. Now, one can have only a maximum of 20 requests per session, if one goes more than that which means if one makes 20 requests in a row one will be logged out. Besides this, there's an overall boundation of 100 requests per 5 mins. So, which means if one re-login and make more than 20 requests and one repeat this thing within 5mins (20*5) = 100 requests in 5 mins (with the same IP) One will be blocked again

You can use VPN to change IPs frequently ....but to get 10 tries again n again you have to enter OTP again n again ...if his is automated and as @520rahul said make it optional to search for slot on manual basis ...it will be more helpful to book slots

First attempt would be to go with manual OTP and fixing the issue with the hard refresh limit. Once that is done, we can see how to efficiently do Auto OTP

[SRvSaha]

@SRvSaha in my opinion if u make changes in exe and after login make it optional to search for slot on manual basis (like hitting enter whenever slot comes by getting notification on telegtam) insteqd of automatic basis that would may work

Yes that would be a work around that we leave the finding part and focus on only the booking part. But however issue what happens is the slots get booked from the time notifications are received to the time booking is attempted (includes time for OTP as well)

[SRvSaha]

Guys, this is what is on my mind:

1. Try to search for slots based on Protected find* APIs
2. If hard refresh limit is met then regenerate OTP and then use Public find* APIs
3. Once slot if found, directly proceed for booking using Protected API
4. In case during Booking, 10+ attempted are made and hard refresh limit is hit, resend OTP as done for Session Regeneration.
5. Remove the Captcha thing so that time reduces
6. Also, when searching for slots, somehow sort centers found in Descending order so that changes of booking is higher (usually people attempt for the first one in the list)

I think this flow would work. Shall make the necessary changes and release a new v5.1.1 version. Shall inform once done, please check it out and see if it is working. I will try to do testing from my end.

[520rahul]

Guys, this is what is on my mind:

1. Try to search for slots based on Protected find* APIs
2. If hard refresh limit is met then regenerate OTP and then use Public find* APIs
3. Once slot if found, directly proceed for booking using Protected API
4. In case during Booking, 10+ attempted are made and hard refresh limit is hit, resend OTP as done for Session Regeneration.
5. Remove the Captcha thing so that time reduces
6. Also, when searching for slots, somehow sort centers found in Descending order so that changes of booking is higher (usually people attempt for the first one in the list)

I think this flow would work. Shall make the necessary changes and release a new v5.1.1 version. Shall inform once done, please check it out and see if it is working. I will try to do testing from my end.

@SRvSaha this sounds great. All b best boss. I know only u can do it. Kudos to u

[deepgandhi]

@SRvSaha I have tried find* API. There is no hard limit of 10, but it stopped giving response of 194, I don't know why such odd number?

[SRvSaha]

@SRvSaha I have tried find* API. There is no hard limit of 10, but it stopped giving response of 194, I don't know why such odd number?

Okay thanks for the confirmation @deepgandhi I'll check. In the meantime, if possible for your, call the find* Protected APIs using Bearer Token in the header and see if there is any hard limit

[deepgandhi]

@SRvSaha I have tried using Bearer token only, I have submitted the merge request, you can check my entire python script there.

[deepgandhi]

@SRvSaha I was able to do more then 500 request using Bearer token in Protected findByDistrict API.

[SRvSaha]

Thanks a lot @deepgandhi. I shall check that. Shall be busy tonight and tomorrow, once I get time shall check it.

[SRvSaha]

@SRvSaha I was able to do more then 500 request using Bearer token in Protected findByDistrict API.

Try the same with findByPIN API as well. Also, tally the difference in response of findByPIN Protected vs findByPIN Public as most of our users use PIN to search rather than district. If you see that both are almost having same results at the same time, there there is almost no caching and we are good to go. Otherwise we will be in trouble as we faced with calender Public APIs. @deepgandhi

[deepgandhi]

@SRvSaha I was able to do more then 500 request using Bearer token in Protected findByDistrict API.

Try the same with findByPIN API as well. Also, tally the difference in response of findByPIN Protected vs findByPIN Public as most of our users use PIN to search rather than district. If you see that both are almost having same results at the same time, there there is almost no caching and we are good to go. Otherwise we will be in trouble as we faced with calender Public APIs. @deepgandhi

I will try the same @SRvSaha

[kukzile]

I used this application for two days on 4th and 5th June and I haven't been able to login to CoWIN since today evening. It is giving USRAUT0018 error and not generating OTP. I checked today morning and it was working fine. Is it a known problem? Are they blocking numbers which are using automated methods?

[520rahul]

I used this application for two days on 4th and 5th June and I haven't been able to login to CoWIN since today evening. It is giving USRAUT0018 error and not generating OTP. I checked today morning and it was working fine. Is it a known problem? Are they blocking numbers which are using automated methods?

@SRvSaha @kukzile me also faced the same issue today. And i found out many people have also faced the same issue. I think cowin has put blocking period after certain no. Of login on the portal

[520rahul]

I found this video on youtube regarding cowin cache. @SRvSaha can it be useful???

https://youtu.be/hf44_-qqddY

[SRvSaha]

@betagoyal @deepgandhi @kukzile @Suren1978 @govindasomani @520rahul @Tnu02 Version 5.2.0 is out now will all the fixes suggested here along with new features for better UX. Thank you all for your patience and support. Check it out and share your feedback!

[SRvSaha]

I found this video on youtube regarding cowin cache. @SRvSaha can it be useful???

https://youtu.be/hf44_-qqddY

May be yes. But since we dropped calender* APIs, it's not going to help us!

[SRvSaha]

I used this application for two days on 4th and 5th June and I haven't been able to login to CoWIN since today evening. It is giving USRAUT0018 error and not generating OTP. I checked today morning and it was working fine. Is it a known problem? Are they blocking numbers which are using automated methods?

@SRvSaha @kukzile me also faced the same issue today. And i found out many people have also faced the same issue. I think cowin has put blocking period after certain no. Of login on the portal

There may be the chance that OTPs are not sent to mobile number for certain time. But I get OTPs ample number of times today. Probably Auto OTP Readers are the reason for this blocking. I tried by best to minimize the requirement of OTP in v5.2.0, see if that helps

[SRvSaha]

I used this application for two days on 4th and 5th June and I haven't been able to login to CoWIN since today evening. It is giving USRAUT0018 error and not generating OTP. I checked today morning and it was working fine. Is it a known problem? Are they blocking numbers which are using automated methods?

https://www.dqindia.com/cowin-otp-issues-arise-citizens-platform-displays-generate-otp-failed-message/ https://www.dqindia.com/cowin-displays-generate-otp-failed-usraut0018-errors-citizens-unable-book-slots-second-dose-covid-19-vaccine/ @520rahul @kukzile