Does a "Too Many Requests 429. Skipping..." error mean that check-in will fail?

[gene1wood]

When I run the docker container, passing in confirmation number, first and last, and the output shows something like

auto-southwest    | Requesting error during fare check. Too Many Requests 429. Skipping...
auto-southwest    | Requesting error during fare check. Too Many Requests 429. Skipping...

Is that an ephemeral error, and when it's time to check-in for the flight it will work? Or is that an indicator that something isn't working and when check-in time comes around it will fail?

I get this with a docker-compose.yml that looks like this

services:
  auto-southwest:
    image: jdholtz/auto-southwest-check-in
    container_name: auto-southwest
    restart: on-failure
    environment:
      - AUTO_SOUTHWEST_CHECK_IN_NOTIFICATION_URL=ntfys://RECACTED/
      - AUTO_SOUTHWEST_CHECK_IN_CONFIRMATION_NUMBER=REDACTED
      - AUTO_SOUTHWEST_CHECK_IN_FIRST_NAME=REDACTED
      - AUTO_SOUTHWEST_CHECK_IN_LAST_NAME=REDACTED

[gene1wood]

It looks like indeed, seeing that error means that later when checkin is attempted it will fail.

When it was time to checkin, the tool errored with this message

auto-southwest    | Checking in to flight from 'REDACTED' to 'REDACTED' for REDACTED
auto-southwest    | 
auto-southwest    | Error: Failed to check in to flight REDACTED for REDACTED. Reason: Too Many Requests 429.
auto-southwest    | Check in at this url: https://mobile.southwest.com/check-in

Well that's disappointing. I guess this tool isn't working currently or is unable to avoid being detected as a bot from Southwest.

[jdholtz]

Is that an ephemeral error, and when it's time to check-in for the flight it will work?

Yes, that error does happen occasionally (perhaps less using #283), especially during fare checking. However, half an hour before check-in new headers are refreshed from Southwest so they won’t be the same as the headers used for this request that results in the error.

It’s possible that the check-in could fail again, but I haven’t seen that happen personally and no issues have been reported about that recently.

[gene1wood]

@jdholtz If #283 is present in the current latest docker image, then I'm using code that contains #283

A moment before you commented, I added a comment above indicating that indeed, check-in then failed due to a 429 error.

[dmytrokoren]

@jdholtz If #283 is present in the current latest docker image, then I'm using code that contains #283

A moment before you commented, I added a comment above indicating that indeed, check-in then failed due to a 429 error.

Try this image:
docker pull dmytrokoren/auto-southwest-check-in:alpha-legacy

[gene1wood]

I'll try that forked docker image.

[gene1wood]

@jdholtz One other question; I was thinking that maybe Southwest would trust a client more if they were logged in with a Southwest account, than if they're just checking into a flight using confirmation number, first and last name.

Have you observer or heard from any folks that the 429 error is more prevalent when not using a Southwest account?

[jdholtz]

No, there hasn’t been any observed data on that. Check-ins aren’t affected by logging in or not though. Headers are always refreshed from a non-logged in state (as long as the check-in is more than 30 minutes away from when it is scheduled).