Airline Load Data API Summary
Goal: Get number of open seats and number of people on standby list per flight.
United Airlines - BEST
Endpoints
| Endpoint |
URL |
| Standby List |
POST https://mobileapi.united.com/standbylistservice/api/GetStandbyList |
| Upgrade List |
POST https://mobileapi.united.com/upgradelistservice/api/GetUpgradeList |
| Flight Status |
GET https://mobileapi.united.com/flightstatusservice/api/GetFlightStatus_UAandStar |
| Flight Status (segment) |
GET https://mobileapi.united.com/flightstatusservice/api/GetSegmentFlightStatusWithDestination_UAandStar |
| Pass Rider List |
POST https://mobileapi.united.com/passriderlistservice/api/PassRiderList |
Data Fields (confirmed from embedded mock JSON)
CustomersOnStandbyList — list of passengers on standby
SeatsAvailable — available seat count (nullable)
AvailabiltyCount — availability count string
ShowStandby — whether standby is shown for segment
enableStandbyList — boolean toggle on flight status
enableUpgradeList — boolean toggle on flight status
businessStandByList — business class standby list
standByListPassengers — passenger details
availableSeat11AMto5PM / availableSeatBefore11AM / availableSeatAfter5PM — time-bucketed availability
Security
- No SSL pinning
- No PairIP/anti-tamper
- No emulator detection
- Auth: session-based (needs login token)
Completeness: 95%
- Open seats: YES (
SeatsAvailable, AvailabiltyCount, time-bucketed seat fields)
- Standby count: YES (
CustomersOnStandbyList, standByListPassengers)
- Standby names: YES (passenger objects)
- Upgrade list: YES (separate endpoint)
- Missing: Need to capture actual API request body format. Can do via emulator + mitmproxy since no protections exist.
Delta Air Lines - GOOD
Endpoints
| Endpoint |
URL |
| Airport Standby List |
POST https://www.delta.com/api/mobile/asl |
| Upgrade Eligibility |
POST https://www.delta.com/api/mobile/getUpgradeEligibilityInfo |
| Flight Status |
POST https://www.delta.com/api/mobile/getFlightStatus |
| Flight Status by Leg |
POST https://www.delta.com/api/mobile/getFlightStatusByLeg |
Data Fields
seatsAvailableCount — number of open seats
seatsRemainingLabel — display text for remaining seats
upgradeCount — number on upgrade list
UpgradeSeatRemaining — seats remaining per cabin class
getClearedStandbyPassengers — passengers who cleared
getWaitingStandbyPassengers — passengers still waiting
getStandbyTotalWaitList — total on standby waitlist
getStandbySeatRemaining — seats available for standby
standbyPriority / standbyPriorityCode — priority info
hasStandbyFlightNoSeatsAvailable — boolean indicator
Security
- No SSL pinning
- No PairIP/anti-tamper
- No emulator detection
- Auth: session-based via
/api/mobile/login
Completeness: 90%
- Open seats: YES (
seatsAvailableCount, UpgradeSeatRemaining per cabin)
- Standby count: YES (
getStandbyTotalWaitList, cleared vs waiting)
- Standby names: YES (
StandbyPassengerPositionView, StandbyPassengerStatusAdapter)
- Upgrade list: YES (
upgradeCount, upgradeList)
- Missing: Need to capture actual request/response JSON format. Can do via emulator + mitmproxy. Need to determine if auth is required or if ASL endpoint works without login.
Spirit Airlines - PARTIAL
Endpoints
| Endpoint |
URL |
| BOA Status |
POST https://api.spirit.com/customermobileprod/2.8.0/v1/getboastatus |
| BOA Parameters |
GET https://api.spirit.com/customermobileprod/2.8.0/v1/getboaparameters |
| Flight Search |
POST https://api.spirit.com/customermobileprod/2.8.0/v5/Flight/Search |
Data Fields
isStandby — boolean standby flag
standby — standby details on segment
boaStatus — Board of Availability status
capacity — flight capacity
availableUnits — available units
Security
- No SSL pinning
- No PairIP/anti-tamper
- Akamai Bot Manager present (may block non-app requests)
- Auth: token-based via
/v2/Token
Completeness: 50%
- Open seats: UNCLEAR —
availableUnits and capacity exist but unclear if they represent seat counts. Spirit may not expose granular seat availability.
- Standby count: UNCLEAR —
boaStatus exists but the response format is unknown. Spirit's BOA system is simpler than Delta/United.
- Standby names: UNCLEAR — no
StandbyPassenger model found. May only show status, not individual passengers.
- Missing: Need actual API call to determine what
getboastatus returns. Emulator capture needed. Spirit may have a more limited standby system (being an ULCC).
American Airlines - BLOCKED
Endpoints
| Endpoint |
URL |
| Flight Status (web) |
POST https://www.aa.com/flightinfo/v1.2/ |
| Standby/Waitlist |
UNKNOWN — mobile app only, SSL pinned |
Data Fields (from iOS app screenshot)
- "Available seats: 23" — seat count per cabin
- Passenger names on standby list
- Standby vs Upgrade lists
- Cabin-specific breakdown
Security
- SSL pinning on key domains
- PairIP anti-tamper on Android (crashes on emulators)
- Akamai WAF on web endpoints
Completeness: 20%
- Open seats: CONFIRMED EXISTS (screenshot shows "Available seats 23") but API endpoint unknown
- Standby count: CONFIRMED EXISTS (screenshot shows passenger list) but API endpoint unknown
- Flight status: CAPTURED (
/flightinfo/v1.2/ — gates, times, status, equipment)
- Missing: The standby/waitlist API endpoint is mobile-app-only, protected by SSL pinning (iOS) and PairIP (Android). Cannot be captured without jailbroken iOS device or rooted physical Android with Magisk+Shamiko.
Action Items
Immediately actionable (no additional capture needed):
- AA Flight Status —
/flightinfo/v1.2/ is working. Can get gates, times, delays, equipment.
Needs emulator + mitmproxy capture (no protections, straightforward):
- United Standby List — Boot emulator, install APK, login, call
GetStandbyList. No pinning/anti-tamper. Full data including seat counts and passenger names.
- Delta ASL — Same approach. Boot emulator, install APK, login, call
/api/mobile/asl. Full data.
- Spirit BOA — Boot emulator, install APK, login, call
/v1/getboastatus. Determine what data is actually returned.
Requires physical device:
- AA Standby/Waitlist — Needs jailbroken iPhone + SSL Kill Switch, or rooted physical Android + Magisk + Shamiko + Frida.
Priority order for implementation:
- United (most data, easiest to capture, dedicated standby service endpoint)
- Delta (rich data model, no protections)
- Spirit (uncertain data granularity)
- AA (blocked without specialized hardware)