Announcement

**JuliaS** · 2026-02-25, 15:51

Hi! Thank you for your detailed explanation of the issue.

The approach you are currently using, namely querying the Flight Summary endpoint with a rolling time window, is not producing the expected results primarily because you are tracking general aviation and military flights. For these types of operations, it is typically not possible to reliably determine or predict the expected takeoff time, landing time, or destination in advance.

It is also important to note that first_seen is the timestamp currently used by the Flight Summary endpoints for time based queries.

In such cases, the destination field that you are using as a filtering parameter is often populated later during the flight, or sometimes only after landing has been detected. As a result, a real time query with your selected filters may not return results within a time window overlapping the first_seen timestamp. However, running the same query at a later time may return the expected results once the destination has been populated.

Additionally, if the selected time window does not include the first_seen timestamp, the query will not return results, either in real time or retrospectively.

This approach tends to work well for regularly scheduled commercial passenger flights, where departure and arrival times and destination airports are known or predictable in advance.

For live tracking purposes, we recommend using the Live Flight Position endpoints. These endpoints are specifically designed for real time monitoring and allow filtering by parameters such as altitude and ground speed.

We are currently discussing the possibility of introducing alternative significant flight related timestamps such as datetime_takeoff, datetime_landed, or last_seen in future developments but with no clear timeline for implementation. That said, each of these options would also have certain limitations in your scenario.

The last_seen field is updated with each new position update, meaning you would likely receive the same flight in consecutive queries for as long as it remains active, similar to the behavior of the Live Flight Position endpoints.

The datetime_takeoff field would in most cases yield results similar to first_seen, since the destination for the types of flights you are tracking is typically populated later in the flight.

The datetime_landed field would return the flight only after landing, once this field has been populated.

We hope this clarifies the behavior you are observing.

**chanzer0** · 2026-02-25, 16:16

Thank you for the reply. I do understand the root cause of the issue now with using a rolling time window in conjunction with my query parameters not being set until after the first_seen timestamp has "rolled past" my interval window.

We are currently discussing the possibility of introducing alternative significant flight related timestamps such as datetime_takeoff, datetime_landed, or last_seen in future developments but with no clear timeline for implementation. That said, each of these options would also have certain limitations in your scenario.

This makes sense, although I do think it would at least help my situation somewhat. In the examples I posted, especially the inbound:WBG example, the first_seen timestamp is often hours or some significant portion of time earlier than the next reported timestamp in the downloaded CSV files. In these scenarios, I believe the datetime_takeoff would've been sufficient as I had noticed destinations set for these aircraft both on FR24 and Skycards at the time they took off and were airborne. I do recognize that there may still be issues with certain parameters not being set until later in the flight, but I believe it would be an improvement. As far as using last_seen timestamp resulting in instances of the same flight being returned each time that field was updated, I have some notes or suggestions later in this post about possible exclusion parameters that would preclude these duplicate flights from being returned by the API.

For live tracking purposes, we recommend using the Live Flight Position endpoints. These endpoints are specifically designed for real time monitoring and allow filtering by parameters such as altitude and ground speed.

I have had success in the past using the live flight position endpoints, however I ran into 2 issues with these endpoints that made my use case really inefficient in terms of credit usage. The first is the obvious: each flight returned in these endpoints incurs 8 credits for the full endpoint, and 6 with the light endpoint, compared to 1 credit on the flight summary endpoints (I also do not have any need for the exact lat/long position of these endpoints, which makes it feel like a waste of credits compared to flight summary endpoints, which have all the data I need. I don't want to track flights live positions, I just want an alert on the first instance of them being airborne with my query parameters). This makes it really expensive (in conjunction with my second point) to run any sort of alerting functionality for flights. The second point is that given any query string parameters (inbound destination, ICAO type, registration number), each subsequent call to the endpoint will continue returning flight data, incurring 8 or 6 credits for the duration of the flight at whatever interval I am polling the endpoint at, which unecessarily drains credits incredibly fast as I have no desire to continue tracking the flight once I know about it.

I had spoken with the team via support ticket in the past about ways to mitigate this, which if implemented, would probably be efficient enough for me to return to the endpoint. Some technique by which I can pass "exclusion" query paramters (such as fr24's internal flight_id or some other unique identifier) that would exclude flights that have already been returned to me would be ideal here as it would mitigate the issue of spending 8 or 6 credits on flights I have already seen. This exclusion filter could also apply to other endpoints, such as the flight summary light endpoints. If exclusion filters were possible, I would be able to do away with my "rolling window", which has been the root of many of my problems. Any flight that matched my filter parameters at any point in its flight would be returned, I would be notified of it, and would be able to store the flight_id and pass that in subsequent requests.

Thank you again for your time and response, and look forward to hear any updates about improvements to the API and flight alerting

Announcement

flight_datetime_from & to based on first_seen is unreliable for real-time matching

flight_datetime_from & to based on first_seen is unreliable for real-time matching

Comment

Comment