Live flight data parsing returns N/A for Premium (Silver/Gold) accounts

[malosaaa]

@JeanExtreme002

An user did found a bug probably within the latest api update since 1.4.1 i did debug this.
I bumped the api to 1.5.1 and yet its not yet working.

Here is the issue:

When a user logs in with a Premium account (Silver/Gold), the FR24 live flights array structure changes. This breaks the Flight parser in the library, causing properties like altitude, ground_speed, and squawk to return None or N/A."

So when the user logs out it shows up again, of course without the premium data.

AlexandrErohin/home-assistant-flightradar24#217 (comment)

regards

[JeanExtreme002]

Hi @malosaaa!

This actually sounds much more like a change on FlightRadar24's side than a regression in the SDK itself. The library was originally designed with the free-tier user in mind, so the parser assumes the response shape that FR24 returns for unauthenticated/free accounts. If they've changed the payload structure specifically for Silver/Gold sessions, the parser wouldn't know how to handle the new fields — and that would line up exactly with the None or N/A behavior you're describing.

That said, I'm pretty tied up with other things at the moment and I don't currently have a premium account on
hand to reproduce the issue, so it'll be hard for me to dig into this one in the short term.

I'd really appreciate any help from the community here. Two ways you (or anyone reading this) could move it forward:

1. Open a PR updating the parser to handle the premium payload — happy to review and merge.
2. Share a sample of the raw response returned by the FR24 endpoint when logged in with a premium account. With a concrete example of the new structure in hand, I should be able to patch the parser more easily.

[malosaaa]

I really want to test but sadly i have no premium tier, depends if someone wants to share it with me so i can look into it.
But i am ready to help no worries i do what i can to help.
Otherwise i will if no one is subscribed take a subscription to help out. i let u know Jean.

Regards

[malosaaa]

I gonna subscribe now, so no worries i report back and do the PR ;)

[malosaaa]

@JeanExtreme002

Hi Jean,

I subscribed to a Silver account to help debug this and found the exact root cause.

The issue isn't that the parser is failing to read new premium fields. The problem is that the get_flight_details() endpoint (the clickhandler) intercepts the request for authenticated premium users.

When using api.get_flight_details(flight) with a logged-in Silver session, the FR24 server does not return the normal flight payload. Instead, it returns a single dictionary containing an "s" token (which appears to be a security signature or session challenge):

{
    "s": "C765yZxp1RFQhOCpH7...[REDACTED]..."
}

Because the actual flight data payload isn't downloaded, downstream integrations (like Home Assistant) end up returning None or N/A for all the premium values (like SQUAWK, vertical speed, etc.) because the fields simply aren't there.

It looks like the library needs to be updated to either pass a specific premium header to the clickhandler to prevent this interception, or automatically handle this "s" signature challenge to retrieve the actual payload.

I have my Silver account ready, so let me know if you need me to test any PRs!

[malosaaa]

Hi Jean,

I ran extensive tests today using a test script on both a Free account and a Silver account. Here are the definitive findings:
This user claims when he logs in he doesnt get some data thats also for the free tier, and it was missing squawk right
AlexandrErohin/home-assistant-flightradar24#217 (comment)
However i did this test and it did return perfectly fine :
get_flights() works perfectly.

C:\Users\Administrator\Desktop\debug flightradar>py test_map_shift.py
--- PHASE 1: FREE TIER MAP DATA ---
APIRequest.get_content: failed to decode Content-Encoding='gzip' for https://data-cloud.flightradar24.com/zones/fcgi/feed.js (Not a gzipped file (b'{"')). Assuming the transport already decompressed and returning raw bytes.
Callsign:    KLM701
Altitude:    36400
Heading:     201
Groundspeed: 464
Squawk:

--- PHASE 2: SILVER TIER MAP DATA ---
APIRequest.get_content: failed to decode Content-Encoding='gzip' for https://www.flightradar24.com/user/login (Not a gzipped file (b'{"')). Assuming the transport already decompressed and returning raw bytes.
APIRequest.get_content: failed to decode Content-Encoding='gzip' for https://data-cloud.flightradar24.com/zones/fcgi/feed.js (Not a gzipped file (b'{"')). Assuming the transport already decompressed and returning raw bytes.
Callsign:    KLM701
Altitude:    36325
Heading:     201
Groundspeed: 464
Squawk:      2714

My theory
The library parses the live map array without any issues on both Free and Silver. When logged in, it successfully retrieves premium fields (like the squawk code) without any array-shifting or parsing errors.

get_flight_details() is being blocked by a WAF. Whenever the Python library requests flight details (logged in or out), FlightRadar24's anti-bot firewall intercepts it and returns a security challenge token: {"s": "..."} instead of the payload.

The impact on downstream integrations (like Home Assistant):
Integrations are fetching the map data (which works), but when they attempt to append data from get_flight_details(), they receive the empty WAF token. This causes the integrations to drop or overwrite the valid map data, resulting in None or N/A for Altitude, Heading, Squawk, etc.

The fix will likely require updating the library's request headers or using a TLS/Cloudflare bypass to allow get_flight_details() to get past the firewall and reach the actual JSON payload again.