Getting error 429 during fare checks and logins #201
Comments
|
Thanks for reporting this. Unfortunately, I am unable to reproduce this issue. Can you reproduce this with the A 429 Error usually happens when Southwest is detecting that you are using a bot. Are you using a VPN on the computer running the script? Many people have gotten 429 errors before, so there may be some common troubleshooting steps in past issues for you to try. What I noticed is that the request it fails at is a POST request. The only other time a POST request is sent is during check-in, so it may fail to check in for you too. |
|
I am able to reproduce this with the develop branch. I am not using a VPN. I think I'll wait until tomorrow and see if I continue to get this error tomorrow. Maybe it's a fluke. |
|
I don't know if it's related, but the first flight (of the four that it attempts to check) has an error like this: caused by the flight being rescheduled by Southwest. Maybe this has downstream effect to the later requests that get sent? I am not sure on that. I have seen it successfully make at least one or two successful fare checks since I started seeing the errors. |
|
FWIW I get the same error on v6.1. |
That just means the flight's fares cannot be checked because the Southwest website doesn't allow you to go in and view the same flight's fares but it is not the cause of the issue. There was an issue with flight rescheduling in this script, but that has been fixed on the latest This may be a random issue that happens occasionally (I'm unsure what and why it occurs though). We can wait for a few days and see if it is indeed a fluke. |
I think that's what we should do. Running the script on a different computer has no issues. Granted the other computer is Windows (instead of Linux) and the script is running natively (not in docker). Nevertheless, it's not like my IP is banned because both computers are on the same network. I'll report back later. |
|
Some new theories. I restarted the docker container this morning. The first three flights that it checked were successful. The following five flights that it attempted to check all got 429 errors. Of those five, the last four were in a second account. I restarted it again. This time, the fare check was successful for all of the flights in the first account, but failed for the flights in the second account (4 success and 4 fails). I did print out the response headers on the failing requests and unfortunately there is no key telling you when the rate limit resets. Note that these issues all occurred on my linux home server. I decided to run it again on my Windows laptop. I reliably get the same errors when running the docker container on my laptop too. However, running the python program outside of the docker container works, every time. Thinking that maybe it was my home internet somehow, I tried again with my laptop and docker container on my cell phone hotspot - same 429 error. It really seems to me like there is something about the docker container that is being detected by Southwest. I am open to debugging this further but I am wondering if you have any ideas of what to look at next. I am also a bit surprised you're not seeing this. |
|
One more thing I just tried. I tried adding in 90 second sleeps between the retries in util.py and a 90 second sleep in fare_checker.py _get_matching_flights right before it does the search. I still get a 429 error when running in docker. |
|
I have started getting 429 errors in the last week or so as well. I am running the script in a docker container on my Linux home server. I get the error for fare checks and this morning I got it for flight check-in unfortunately. It logs into my accounts (two accounts) with no issues. Is there something about the Docker container that Southwest is picking up on? Edit: running v7.1, no VPN or proxy Log
2024-01-10 17:51:38 DEBUG MainProcess[log:23]: Initialized the application
2024-01-10 17:51:38 DEBUG MainProcess[main:112]: Auto-Southwest Check-In v7.1
2024-01-10 17:51:38 DEBUG MainProcess[main:113]: Called with 0 arguments
2024-01-10 17:51:38 DEBUG MainProcess[config:107]: Initializing configuration file
2024-01-10 17:51:38 DEBUG MainProcess[config:135]: Reading the configuration file
2024-01-10 17:51:38 DEBUG MainProcess[config:53]: Setting check fares to True
2024-01-10 17:51:38 DEBUG MainProcess[config:67]: Setting notification level to <NotificationLevel.INFO: 1>
2024-01-10 17:51:38 DEBUG MainProcess[config:80]: Using 2 notification services
2024-01-10 17:51:38 DEBUG MainProcess[config:84]: Setting retrieval interval to 24 hours
2024-01-10 17:51:38 DEBUG MainProcess[config:118]: Creating configurations for 2 accounts
2024-01-10 17:51:38 DEBUG MainProcess[config:125]: Creating configurations for 0 reservations
2024-01-10 17:51:38 DEBUG MainProcess[main:142]: Monitoring 2 accounts and 0 reservations
2024-01-10 17:51:39 DEBUG Process-1[reservation_monitor:154]: Acquiring lock...
2024-01-10 17:51:39 DEBUG Process-1[reservation_monitor:156]: Lock acquired
2024-01-10 17:51:39 DEBUG Process-1[reservation_monitor:178]: Retrieving reservations for account
2024-01-10 17:51:39 DEBUG Process-1[webdriver:103]: Starting webdriver for current session
2024-01-10 17:51:39 DEBUG Process-2[reservation_monitor:154]: Acquiring lock...
2024-01-10 17:51:42 DEBUG Process-1[webdriver:119]: Using browser version: 117.0.5938.62
2024-01-10 17:51:42 DEBUG Process-1[webdriver:123]: Loading Southwest Check-In page
2024-01-10 17:51:55 DEBUG Process-1[webdriver:80]: Logging into account to get a list of reservations and valid headers
2024-01-10 17:51:59 DEBUG Process-1[webdriver:152]: Waiting for headers_set to be set
2024-01-10 17:51:59 DEBUG Process-1[webdriver:156]: headers_set set successfully
2024-01-10 17:52:03 DEBUG Process-1[webdriver:144]: Login response has been received
2024-01-10 17:52:03 DEBUG Process-1[webdriver:152]: Waiting for login_request_id to be set
2024-01-10 17:52:03 DEBUG Process-1[webdriver:156]: login_request_id set successfully
2024-01-10 17:52:03 DEBUG Process-1[webdriver:226]: First time logging in. Setting account name
Successfully logged in to John Doe's account
2024-01-10 17:52:03 DEBUG Process-1[webdriver:152]: Waiting for trips_request_id to be set
2024-01-10 17:52:04 DEBUG Process-1[webdriver:148]: Upcoming trips response has been received
2024-01-10 17:52:04 DEBUG Process-1[webdriver:156]: trips_request_id set successfully
2024-01-10 17:52:05 DEBUG Process-1[reservation_monitor:197]: Successfully retrieved 1 reservations
2024-01-10 17:52:05 DEBUG Process-1[reservation_monitor:84]: Scheduling flight check-ins for 1 reservations
2024-01-10 17:52:05 DEBUG Process-1[checkin_scheduler:76]: Retrieving reservation information
2024-01-10 17:52:07 DEBUG Process-1[utils:34]: Successfully made request after 1 attempts
2024-01-10 17:52:07 DEBUG Process-1[checkin_scheduler:89]: Successfully retrieved reservation information
2024-01-10 17:52:07 DEBUG Process-1[checkin_scheduler:57]: 2 flights found under current reservation
2024-01-10 17:52:07 DEBUG Process-1[checkin_scheduler:43]: 2 total flights were found
2024-01-10 17:52:07 DEBUG Process-1[checkin_scheduler:100]: 2 new flights found
2024-01-10 17:52:07 DEBUG Process-1[checkin_scheduler:104]: Scheduling 2 flights for check-in
2024-01-10 17:52:07 DEBUG Process-1[checkin_handler:41]: Scheduling check-in for current flight
2024-01-10 17:52:07 DEBUG Process-1[checkin_handler:41]: Scheduling check-in for current flight
2024-01-10 17:52:07 DEBUG Process-1:1[checkin_handler:81]: Check-in time has passed. Going straight to check-in
2024-01-10 17:52:07 DEBUG Process-1:1[checkin_handler:124]: Attempting to check in
Checking in to flight from 'Minneapolis/St. Paul (Terminal 2)' to 'Denver' for John Doe
2024-01-10 17:52:07 DEBUG Process-1:1[checkin_handler:138]: Making GET request to check in
2024-01-10 17:52:07 DEBUG Process-1[notification_handler:66]: Sending new flights notification
Successfully scheduled the following flights to check in for John Doe:
Flight from Minneapolis/St. Paul (Terminal 2) to Denver at 2024-01-11 12:40:00 UTC
Flight from Denver to Minneapolis/St. Paul (Terminal 2) at 2024-01-15 13:50:00 UTC
2024-01-10 17:52:07 DEBUG Process-1:2[checkin_handler:89]: Sleeping until thirty minutes before check-in...
2024-01-10 17:52:09 DEBUG Process-1[checkin_scheduler:116]: 2 flights are currently scheduled. Removing old flights
2024-01-10 17:52:09 DEBUG Process-1[checkin_scheduler:132]: Successfully removed old flights. 2 flights are now scheduled
2024-01-10 17:52:09 DEBUG Process-1[reservation_monitor:93]: Checking fares for 2 flights
2024-01-10 17:52:09 DEBUG Process-1[fare_checker:30]: Checking current price for flight
2024-01-10 17:52:09 DEBUG Process-1[fare_checker:88]: Fetching reservation information
2024-01-10 17:52:11 DEBUG Process-1[utils:34]: Successfully made request after 1 attempts
2024-01-10 17:52:11 DEBUG Process-1[fare_checker:103]: Retrieving search information for the current flight
2024-01-10 17:52:12 DEBUG Process-1[utils:34]: Successfully made request after 1 attempts
2024-01-10 17:52:12 DEBUG Process-1[fare_checker:82]: Retrieving matching flights
2024-01-10 17:52:17 DEBUG Process-1[utils:41]: Failed to make request after 7 attempts: Too Many Requests 429
2024-01-10 17:52:17 DEBUG Process-1[utils:44]: Response body: {
"code": 429999999,
"message": "Error.",
"messageKey": "ERROR",
"httpStatusCode": "BAD_REQUEST",
"requestId": "",
"infoList": []
}
2024-01-10 17:52:17 ERROR Process-1[reservation_monitor:102]: Requesting error during fare check. Too Many Requests 429. Skipping...
2024-01-10 17:52:17 DEBUG Process-1[fare_checker:30]: Checking current price for flight
2024-01-10 17:52:17 DEBUG Process-1[fare_checker:88]: Fetching reservation information
2024-01-10 17:52:19 DEBUG Process-1[utils:34]: Successfully made request after 1 attempts
2024-01-10 17:52:19 DEBUG Process-1[fare_checker:103]: Retrieving search information for the current flight
2024-01-10 17:52:21 DEBUG Process-1[utils:34]: Successfully made request after 1 attempts
2024-01-10 17:52:21 DEBUG Process-1[fare_checker:82]: Retrieving matching flights
2024-01-10 17:52:22 DEBUG Process-1:1[utils:41]: Failed to make request after 20 attempts: Too Many Requests 429
2024-01-10 17:52:22 DEBUG Process-1:1[utils:44]: Response body: {
"code": 429999999,
"message": "Error.",
"messageKey": "ERROR",
"httpStatusCode": "BAD_REQUEST",
"requestId": "",
"infoList": []
}
2024-01-10 17:52:22 DEBUG Process-1:1[checkin_handler:147]: Failed to check in. Error: Too Many Requests 429. Exiting
2024-01-10 17:52:22 DEBUG Process-1:1[notification_handler:108]: Sending failed check-in notification...
Failed to check in to flight XXXXX for John Doe. Reason: Too Many Requests 429.
Check in at this url: https://mobile.southwest.com/check-in |
|
I just started using the application this morning, but having the same issue attempting to run as a docker daemon on my home server. I was able to run (via docker compose) in the foreground and successfully check in, only when deploying as a daemon I hit the 429. |
I have the same experience. I get errors with |
|
I tried v7.1 on two machines I have (each on different networks) and none of them hit a 429. I also tried with the docker-compose example from the Readme using the
It doesn't seem to be rate limiting because, as you said later, adding a delay between requests does not circumvent the issue. Could someone paste the headers they are using? Maybe there is something interesting with them that tells Southwest you are a bot. Add |
Headers
|
|
I got a "Reason: Too Many Requests 429" when it went to try to check me in yesterday. It happened for me and another person for a different flight. I'm on 7.1 as well. I only have price checking interval at every 12 hours, so I don't think I triggered a southwest block or anything. No VPN either. |
|
Thanks @sevenlayercookie. Doesn’t seem like anything out of the ordinary. Is anyone who is getting this error running this with |
|
I just got a 429 trying to check-in for my flight this morning. I'm running the script with just |
|
I can now reproduce this issue while running in Docker (even with the |
|
I was able to check in to some flights this morning without any issue. Same version I was on previously with no changes. Using Docker image on my qnap nas. |
Did some flights still fail to check in with the 429? |
Not today, my flight and another person (2 different accounts and flight times) on 1/10/24 during check-in I got a 429. Today, I had no issues checking in. |
I got one 429 today during the fare check, with seven successful fare checks. |
|
I got a 429 today on a flight check-in, I can try restarting the docker container and seeing if that fixes it for the returning flight in a few days. Would turning off the fare check help any? Right now mine's set to the default 24 hours. |
Unfortunately not. I will look to see if I can fix this issue soon. |
|
FYI...Getting same error on flight checkin today. Successfully worked month of Dec '23. LogsSuccessfully scheduled the following flights to check in for YYYYY: |
|
Thanks for the logs. I haven't had much time to look into this right now, but I can later this afternoon. Currently, it seems like people are having issues in Docker but not when running it with Python (at least, this is my case). The logs and headers are not anything outside of the ordinary. Something with Docker is probably making Southwest detect the bot (not sure what though). |
|
I've done some debugging. Unfortunately, I haven't come closer to finding the issue and am not sure how to move forward, but I will detail what I have done so far below. It would be great if other people can help debug so we can resolve this. Most likely not the issue:
Potentially the issue:
These are only the situations I have looked into. Let me know if you guys think of anything else to try/debug it yourselves. |
|
Just to highlight an earlier data point - my previous comment called out a failure from just running the script directly in Python. No Docker involved. I had both legs of my checkin fail with a 429 (same bad request message too). I did run this from an AWS EC2 instance so it is possible they flagged my EIP as a potential bot. |
Ah, thanks for pointing that out. I doubt they flagged the EIP because many other people are getting the same issue and are running it from their home network. |
|
Makes sense. I actually just (5 minutes ago) got this failure again after using |
You can add this to your compose file for debug logs: command: ["--verbose"] |
For @dmytrokoren and anyone else that doesn't have reservations (I also don't right now), the 403 error can still be reached by inputting fake reservation information.
@bradzab0623 possibly. I'm not exactly sure how rollouts are done (and it can be done many ways), but it could still be a staggered rollout because your computer could be routed to some of their servers that have the new changes and routed to others with the old changes still (you wouldn't be in control of where you are routed). If this were the case, it could explain why you receive different results for the same accounts |
@jdholtz but he was login in to his account and from there the reservation was giving 403. Sorry I'm just trying to understand. |
Exactly. Just add arguments like |
|
Is anyone still getting a 429 error? If not, I will close this issue in favor of #230 which is now tracking a 403 error (which I believe is just an adjustment made by Southwest, but it is still the same underlying issue as this 429). |
|
nope. just the 403 |
|
No issue with 403 on the start of container. All works as expected. After 2-3 fair checks it starts giving 403 error and no reservations found. It might be that the token/key expires after certain period. That's the only way I can see why 403 is coming up. But if some are facing on container start than I don't know... |
|
I got a 429 yesterday when I tried to check-in but that's probably a different issue compared to fare checks. First time using this, docker, latest build. |
I'm still getting sporadic 403/429 while running the docker version in k3s when checking fares: 2024-02-24 21:00:33 DEBUG Process-1[reservation_monitor:93]: Checking fares for 2 flights
2024-02-24 21:00:33 DEBUG Process-1[fare_checker:30]: Checking current price for flight
2024-02-24 21:00:33 DEBUG Process-1[fare_checker:88]: Retrieving reservation information
2024-02-24 21:00:38 DEBUG Process-1[utils:39]: Failed to make request after 7 attempts: Forbidden 403
2024-02-24 21:00:38 DEBUG Process-1[utils:42]: Response body: {
"code": 403050700
}
2024-02-24 21:00:38 ERROR Process-1[reservation_monitor:105]: Requesting error during fare check. Forbidden 403. Skipping...
2024-02-24 21:00:38 DEBUG Process-1[fare_checker:30]: Checking current price for flight
2024-02-24 21:00:38 DEBUG Process-1[fare_checker:88]: Retrieving reservation information
2024-02-24 21:00:40 DEBUG Process-1[utils:32]: Successfully made request after 1 attempts
2024-02-24 21:00:40 DEBUG Process-1[fare_checker:103]: Retrieving search information for the current flight
2024-02-24 21:00:44 DEBUG Process-1[utils:32]: Successfully made request after 4 attempts
2024-02-24 21:00:44 DEBUG Process-1[fare_checker:82]: Retrieving matching flights
2024-02-24 21:00:49 DEBUG Process-1[utils:39]: Failed to make request after 7 attempts: Too Many Requests 429
2024-02-24 21:00:49 DEBUG Process-1[utils:42]: Response body: {
"code": 429999999,
"message": "Error.",
"messageKey": "ERROR",
"httpStatusCode": "BAD_REQUEST",
"requestId": "",
"infoList": []
}
2024-02-24 21:00:49 ERROR Process-1[reservation_monitor:105]: Requesting error during fare check. Too Many Requests 429. Skipping...But, the most recent check worked just fine: 2024-02-26 21:00:27 DEBUG Process-1[reservation_monitor:93]: Checking fares for 2 flights
2024-02-26 21:00:27 DEBUG Process-1[fare_checker:30]: Checking current price for flight
2024-02-26 21:00:27 DEBUG Process-1[fare_checker:88]: Retrieving reservation information
2024-02-26 21:00:29 DEBUG Process-1[utils:32]: Successfully made request after 1 attempts
2024-02-26 21:00:29 DEBUG Process-1[fare_checker:103]: Retrieving search information for the current flight
2024-02-26 21:00:31 DEBUG Process-1[utils:32]: Successfully made request after 1 attempts
2024-02-26 21:00:31 DEBUG Process-1[fare_checker:82]: Retrieving matching flights
2024-02-26 21:00:33 DEBUG Process-1[utils:32]: Successfully made request after 1 attempts
2024-02-26 21:00:33 DEBUG Process-1[fare_checker:50]: Found 10 matching flights
2024-02-26 21:00:33 DEBUG Process-1[fare_checker:37]: Flight price change found for +1 USD
2024-02-26 21:00:33 DEBUG Process-1[fare_checker:30]: Checking current price for flight
2024-02-26 21:00:33 DEBUG Process-1[fare_checker:88]: Retrieving reservation information
2024-02-26 21:00:35 DEBUG Process-1[utils:32]: Successfully made request after 1 attempts
2024-02-26 21:00:35 DEBUG Process-1[fare_checker:103]: Retrieving search information for the current flight
2024-02-26 21:00:37 DEBUG Process-1[utils:32]: Successfully made request after 1 attempts
2024-02-26 21:00:37 DEBUG Process-1[fare_checker:82]: Retrieving matching flights
2024-02-26 21:00:39 DEBUG Process-1[utils:32]: Successfully made request after 1 attempts
2024-02-26 21:00:39 DEBUG Process-1[fare_checker:50]: Found 10 matching flights
2024-02-26 21:00:39 DEBUG Process-1[fare_checker:37]: Flight price change found for +29 USD |
|
I'm getting 403 right on the start of container. I think southwest is making changes as we speak.... |
I experienced a 429 error on my two attempts to use this script, once on 2/20 and again on 2/27. Here is the verbose log for the most recent attempt: Let me know if any additional information is helpful here! |
|
not sure if this is helpful, I was get 403 error. I turned on VPM and was able to run a check-in using docker which it saying 'successfully scheduled the following flights to check in . . . ." I then tried to add a 2nd reservation and got the 403 error message. I switched the VPN to a new location and the 2nd reservation has been successfully scheduled . . . |
|
I'm not sure what's happening with the comments, but some discussion on March 20th on other related github projects had mentioned an apiguard3 being the culprit.. I linked to that comment on here.. and now I can't find any mention of either comment. Later, I saw someone point the finger at F5's acquisition of Shape Security. It's believed that is the software that is causing all the headaches for automation such as this. Read about it here: https://community.f5.com/kb/technicalarticles/what-is-shape-security/284359 Save this comment if you see it, because who knows how long it'll be here!? I glanced through that article. I'm a network engineer, and, well, I wouldn't want to be on either side of this battle, as it's going to be tough for either side to "win". The bot security side has more money to throw at the problem, I fear. I think the routine price checking, and likely the click rate and lack of javascript being triggered by human mouse movements is likely easily setting off some red flags. If you can emulate an erratic human using an actual browser, then this should still be possible. But, that may defeat the purpose of being first to check in, if you have to emulate slow typing and mouse movements, etc. ;) |
@tjs198 Thanks for the info. I don't think Southwest is blocking due to the location of the ISP because I have been able to hit a 403 on a server from the same ISP as my laptop which doesn't hit the 403. The inconsistency in the 403s could be explained by the article I quoted below which explains that AI is used to help detect bots (which isn't 100% effective).
@hildebrau really interesting article, thanks for sharing. I actually think that's a really cool system and definitely am for it. I am not very familiar with bot detection--all that work is done by SeleniumBase--and trying to evade this system is something I don't want to spend a lot of time doing. I wanted to see how far I can take this project. Eventually, though, I know the cat-and-mouse game will end and with a system like this and 403s being hit by many people using this script, that end may be near. |
|
@jdholtz I think I speak for everyone when I say Don't give up! |
|
Although I do wonder, instead of checking the fares all at once maybe spread out each check within a timeframe? What I've noticed is that if we have several flights already booked, we're probably more likely hit the Too Many Requests 429 error since it would seem like we're spamming the site. (It's happened to me more recently as I've booked more flights for my wife and I in the year). Since she probably ends up flying more than I and our itineraries at least for mine will align with hers, I just took my info off to reduce an additional check for X number of flights. There may be a magic number as to how many we should be concurrently checking. Although, a though in improving, but may make it more complex is the ability to first parse the reservation #'s, and determine if you have any duplicate reservation numbers to reduce the # of responses we need to check for and/or processes that should occur? Or even schedule out some of the processes so they're not necessarily immediately after +5m-10m after each process or even possibly add a randomization like discussed in some other previous post? |
Don't worry, I definitely won't. I'll keep focusing on making the project the best I can.
@babehboi that probably would be an improvement and wouldn't be hard to implement. Can definitely look into this.
With the way the script is currently structured (a separate process for each account), that would be difficult to check for duplicates between reservations. Although this could help a little bit, the situation is quite rare and probably not worth it compared to the complexity it brings in the script. I think the simpler solution would be to do what you recommended above--spread out checking fares.
Have you been getting a 429 only when checking fares? Or also while scheduling reservations or checking in? |
|
@jdholtz What I've noticed is that on the initial load and it's logging into my wife's account, it finds and schedules all the reservations. However shortly after that when it does try to check for fares, that's when I'm getting the errors. However, after 24h, it seems to go about its merry way. I'd want to say this is scheduling about 9 flights if I recall. Interestingly, by the time it gets to a friend's account it was able to check-in and check fares okay. I should note it is a combination of error 429 & 403 as we've probably discovered earlier. If it were up to me, I'd probably add 30s or some random value between 30-60s each of the fare checks? And possibly adding the confirmation number into the log too? I think it would help us clearly troubleshoot where/when it might be occurring? Because as of now, I won't know which reservation failed the checks versus which ones went through. I can only make assume that after the 9 were scheduled the first 3 fare checks failed (429, 429, 403) then 2 passed then 4 failed again (403 x 4) (The time from which it failed to completed was about 20s from each other) next failure happened roughly 20s later. |
|
As the fare prices normally does not change for a day or two, why not even spread them out more than that. I do not know how often the script actually runs stuff like this now, but why not create a routine that creates a random time between 5min and 15mins per say... Then the next check would run say at 6:18, the next one at 11:34, the next one at 7:02, etc... |
|
@netwavetech I believe it runs every 24h today, not sure how often fare prices change or if it's related to moon cycles, but I don't disagree with spreading it out a little more, as much as I'd like things "instantaneously" adding the human element of being slow doesn't hurt a bit in these instances. For what it can do is already great =) |
@babehboi I think it would be good to add this as a configurable value so its up to the user. If you have more flights, you can set this to a longer value, but it allows for setting it to 0 seconds if you only have 1 or 2 flights which 1. probably won't run into the 403/429 that you see due to the volume of requests and 2. not have to wait a long time to get the script's initial results.
@netwavetech you can actually adjust how often the script checks for fares using the |
|
@jdholtz I thought I'd share a thought since I implemented it recently to test my theory of the waiting bit because I noticed I was still consistently 429 or 403, both upon initial run of the script and the subsequent days. Some observations I have which lead me to believe it may be some number game/limitation as I didn't have these issues prior when I had roughly 6 or less legs to check, maybe even 5? So I thought I'd add in a time.sleep(30) in the script just before it attempts to retrieve the reservations. Hopefully to slow things down a bit and see what the outcome was. Although it does seem to initially work, as I wasn't getting the errors immediately following the scheduling of the reservations, but eventually will lead to the same failures. I'll give it a day to see how it goes with subsequent checks, but considering that it goes in and rechecks all reservations and then leads to farecheck errors leads me to believe that their anti-bot detection is at play and works randomly or maybe lengthening the time for which it sleeps before the next check. Which now makes me think, if I put them all as reservations rather than logging into the account if it makes a difference? TL;DR: Attempted to add a delay in checking fares, worked for a bit but still fails. What other things can be tried. |
More my suggestion was not to check every flight retrieved at the exact same time. i.e. I have 6 upcoming flights. Check the first flight, wait 30 mins, 1 Hour, 2Hours, etc Check the next one, and wait for another set of time different from the first, check the next one and so on. So it might look like this. Ideally the mins between would be a random set of time to help trick the bot detection. |
|
After a day and seeing where it would go, it still fails after login and checking for the flights and it's sporadic. So something is looking at the fact that we log in and pull a bunch of flights to make the system think it's a bot...so far the time delay of 30s and 60s does not make any difference in this event. So therefore, I'm testing if I put all 9 legs (7 reservations) to check separately if it would have issues. And to my surprise, it had less issues, only 1 leg failed? So what would be the cause...I do notice that when we log in via the account it doesn't refresh headers before each farecheck? I wonder if that's something we could/should look into? As I recall you mentioning somewhere that, sometimes things error out because we aren't receiving the header somehow? Updated with checking the 7 reservations separately This was launching the search after logging into the account to pull the 7 reservations. If you have any other thoughts to where I should put a delay in your code, let me know, but this was where I thought would make sense: def _get_change_flight_page(self, flight: Flight) -> Tuple[JSON, List[JSON]]: Now looking back and evaluating, maybe I should add it to check_flight_price probably doesn't make a huge difference from my quick read of the order by which each function is pulled, but you know your code better than I would. =) I'll give it a couple days like this and see how it goes. Hopefully others may have found a magic number. |
|
2024-04-22 - auto-southwest-check-in.log So I thought I'd share what I've learned so far in the past 6 days, anecdotally, the bot is probably looking at something the seems very routine or on a certain cadence or schedule. We can see that for the most part all week has been unremarkable until today where every single reservation was 403'd including those that were via login info. We'll see what happens tomorrow, but I may now consider implementing a random number generator prior to each fair check to see what happens, as I'm curious to understand what other ways of spoofing is available, and if time and randomness is our friend. Or if this morning was a fluke and SWA was down. (If anyone knows please comment) Edit: Added this just prior to retrieving flight info, if you have any recommendations let me know. |
Did this work? |
Hey there! So not really well if you're using your account to log in. However it has been more stable when using reservation numbers. Again I think it depends how many that you have in your reservation list and compound that as a daily pull. I'm not sure if my list is small enough. But when I moved it over to reservations in general it skips a lot of other steps and etc so definitely been much much better overall. |
and others
Version
Auto-Southwest Check-In v7.1
Browser Version
Docker image
Description
Recently, I've started getting these 429 errors when checking the prices for upcoming flights. I am not sure if they are truly a 429 error, caused by actually sending too many requests, or a different error being reported as a 429.
To Reproduce
Expected Behavior
No 429 error
Relevant logs and program output
Additional context
No response
The text was updated successfully, but these errors were encountered: