How to Estimate a Flight's Arrival Time (ETA) via API

The arrival ETA is the single most valuable number in flight data — it drives pickups, transfers and connections. Here is how to get a reliable ETA from the API, how it is anchored before and during the flight, and how to use it in local time.

August 2, 2026 · · 5 min read

If you only read one field from a flight, read the estimated time of arrival. It is the number that dispatches a driver, releases a shuttle, holds a connection, and tells a customer when to be at the curb. Get it right and everything downstream lines up; get it from the wrong field and you are early, late, or standing in an empty arrivals hall. This guide shows how to obtain a dependable arrival ETA from the API, how that ETA is anchored at each stage of a flight, and how to present it in the traveller's local time.

What "ETA" actually is

An arrival ETA is a live prediction of when a flight will arrive — not the printed schedule. Before the flight it is anchored to the published schedule; as departure firms up it shifts with the real departure time; once airborne it refines from the aircraft's live progress; and the moment it lands, the estimate is replaced by the recorded actual. A good ETA is simply "the best answer available right now," and which source that comes from changes as the flight progresses.

Getting the ETA from the API

Ask for the flight by number and date. The arrival ETA is the estimated value in the gateArrivalTimes bucket; once the flight lands, the actual value is populated and becomes authoritative.

# resolve a flight and read its arrival times
GET https://api.flightnerve.com/airline/YOUR_KEY?num=72&name=EK&date=20260802

→ [
  {
    "destination": { "iata": "MUC", "TZ": "Europe/Berlin" },
    "gateArrivalTimes": { "scheduled": 1785685200, "estimated": 1785686700, "actual": null },
    "landingTimes":     { "actual": null }
  }
]

Read it with a single fallback — prefer the actual, otherwise the estimate:

# the ETA to act on
eta = gateArrivalTimes.actual or gateArrivalTimes.estimated
arrived = gateArrivalTimes.actual is not None

Sharpening the ETA while the flight is airborne

For a flight in the air, the live position gives you the most current arrival picture. The /track endpoint returns the aircraft's position along with progress and minutes remaining, so you can refine or corroborate the arrival estimate as it descends.

GET https://api.flightnerve.com/track/YOUR_KEY?num=72&name=EK&date=20260802

→ {
  "position": { "lat": 47.9, "lon": 10.8, "altitude": 31000, "phase": "descent" },
  "progress": 0.86,
  "etaMinutes": 24,
  "estArrival": 1785686640
}

Here etaMinutes is a direct "minutes to arrival," and estArrival is the same prediction as an epoch timestamp — convenient for a countdown ("landing in 24 minutes") without any date math.

Showing the ETA in local time

Arrival ETAs are epoch seconds in UTC. The traveller cares about the clock at the destination, so convert using the destination airport's TZ:

# python
from datetime import datetime
from zoneinfo import ZoneInfo
eta_local = datetime.fromtimestamp(1785686700, ZoneInfo("Europe/Berlin"))
# → 16:25 local at MUC

Use the origin's TZ for departure and the destination's for arrival; never render a UTC value as if it were local.

Don't poll for the ETA — let it come to you

If the ETA drives an action, you don't want to poll for it on a timer and hope you catch the change. Create a monitor and receive a webhook whenever the arrival estimate moves past a threshold you set, so a delay reaches your system the instant it is known:

curl -X POST "https://api.flightnerve.com/monitor/YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "flight": "EK72", "date": "20260802", "monitor": { "sensitivity_min": 15 } }'

Now an arrival-delay alert lands on your webhook with the old and new times and the minutes moved — no polling loop, and no missed slip.

Using the ETA well

• Dispatch on the estimate, release on the actual. Stage the driver against the estimated arrival; send them to the curb when the actual (or a landing signal) confirms touchdown.
• Add buffer for the walk, not for the flight. The ETA is gate arrival; taxi-in, immigration and baggage still take time. Apply a fixed post-arrival buffer rather than padding the flight time.
• Trust actual over estimate the instant it appears. Once actual is set, stop using the estimate.

Frequently asked questions

Which field is the arrival ETA?

gateArrivalTimes.estimated. When the flight lands, gateArrivalTimes.actual is set and should be used instead.

What is the difference between estArrival and etaMinutes on /track?

They are the same prediction in two forms: estArrival is an epoch timestamp, etaMinutes is minutes-to-arrival — handy for a live countdown.

How accurate is the ETA before departure?

Before the day it is anchored to the schedule; it sharpens as the real departure firms up and again once the aircraft is airborne and reporting position. Treat it as "best answer now," which improves as the flight progresses.

Do I need to convert to local time myself?

Yes, but it's one step: the value is UTC epoch seconds and each airport ships its TZ, so a standard time-zone conversion gives you the correct local clock.

Should I poll for ETA changes?

For anything that triggers an action, no — create a monitor and receive a webhook when the estimate moves past your threshold. It is fewer calls and you never miss a change.

The arrival ETA is the heartbeat of any flight-driven workflow. Read gateArrivalTimes.estimated, sharpen it with live /track progress while airborne, switch to actual the moment it lands, show it in the destination's local time — and let monitoring push the changes to you instead of polling for them.