How to Track a Connecting Flight Through a Hub

A connection is two flights and one airport. This guide shows how to track the inbound and the outbound legs of a transit correctly, how to pin the exact leg you care about, and how to check the connection actually holds — the difference between meeting a passenger and missing them.

August 10, 2026 · · 6 min read

A connection looks like one journey to the traveller, but to a flight API it is two separate flights that meet at one airport. Track them as a pair and everything downstream lines up: the greeter is at the right gate, the transfer car is booked against the real arrival, and the onward flight is confirmed before anyone leaves home. Track them loosely and you get the classic failures — waiting for a flight that already landed at a different terminal, or dispatching a driver for a departure that was never inbound to that airport at all. This guide shows how to track both legs of a transit correctly.

A connection is two flights and one airport

Every transit has three parts: an inbound flight that arrives at the connecting airport, the airport itself (the hub, where the meet-and-greet or transfer happens), and an outbound flight that departs from it. The two flights usually have different numbers, different aircraft, and different airlines. The only thing they share is the hub — so the hub airport is the anchor you build the whole query around.

Pin the arriving leg, then the departing leg

The subtlety that trips up most integrations is that a single flight number can serve more than one route in a day, so "look up the flight number" is not enough — you have to say which airport you care about. The API lets you pin a leg by its airport:

• For the inbound flight, ask for the leg arriving at the hub. This returns the segment that lands where your greeter is standing, with its scheduled and estimated arrival time, terminal, and aircraft — even when that same flight number also flies onward to somewhere else.
• For the outbound flight, ask for the leg departing the hub. This returns the segment that leaves from the hub, so you do not accidentally quote a different leg of a reused number.

Pinning by airport is what turns "the flight" into "the exact segment my passenger is on." Without it, a flight number that flies A→hub in the morning and hub→B in the evening is ambiguous, and the API cannot know which one you mean.

The same number can fly several routes

Airlines reuse a flight number across the day and across directions. The classic shape is an out-and-back: the aircraft flies hub→city in the evening under a number, and the return city→hub in the morning is sometimes the same number and sometimes a sibling. A number can also be a genuine multi-stop (A→B→C, all one number). The practical rule for a connection is simple: never assume the first or "main" leg is the one you want. State the airport — arriving-at for the inbound, departing-from for the outbound — and let the API return the matching segment.

Check the connection actually holds

Once you have both legs, the connection is only valid if the outbound departs after the inbound arrives, with enough time in between. Read the estimated arrival of the inbound leg and the estimated departure of the outbound leg — both are live values that move as the day develops. A connection that looked comfortable on the schedule can tighten when the inbound runs late, and that is exactly the moment your operation needs to know. Comparing the two live times, rather than the two printed schedules, is what lets you re-plan a transfer before it becomes a missed pickup.

Both flights carry terminal information where it is published, which matters at large hubs: an arrival at one terminal and a departure from another turns a 90-minute connection into a tight one. Reading the terminal on each leg lets you route the passenger, or the greeter, to the right building.

Work in the hub's local time

Everything at the hub happens in the hub's local time — that is when the greeter shows up and when the transfer is booked. Each leg returns its times in two matching forms: a local wall-clock time for the airport, and the same instant in UTC. Use the local time for anything a human reads or acts on at the airport, and keep the UTC value for any calculation that spans the two airports (such as the gap between arrival at the hub and departure onward), so a connection that crosses midnight or a timezone boundary still computes correctly. Mixing the two — doing math on local strings — is the most common source of an "impossible" negative connection time.

A checklist for transit tracking

• Anchor on the hub. The connecting airport is the fixed point; both flights are described relative to it.
• Inbound = arriving leg. Pin the flight to the airport it arrives at, so a reused number resolves to the segment that lands at your hub.
• Outbound = departing leg. Pin the flight to the airport it departs, for the same reason.
• Compare live times, not schedules. Use the inbound's estimated arrival and the outbound's estimated departure to confirm the connection still holds.
• Mind the terminals. Different terminals at the hub change how much time the passenger really has.
• Local time for people, UTC for math. Present the hub's local time; compute the gap in UTC.

Frequently asked questions

My inbound flight number shows a route that does not touch the hub. Why? The number probably serves more than one route that day, and the default answer is another leg. Pin it to the airport it arrives at, and the API returns the segment that lands at your hub.

Do both flights need to be the same airline? No. A connection is defined by the shared airport and the timing, not the carrier. Track each flight number independently and compare their times.

How far ahead can I check a connection? Both legs answer for future dates using the scheduled and projected timetable, so you can validate a connection at booking time and then re-check it live as the day approaches.

What if the inbound is delayed? The inbound's estimated arrival moves in real time. Compare it against the outbound's departure continuously; the moment the gap drops below your minimum, you can re-book the transfer or alert the passenger.

Tracking arrivals, departures and connections is one clean call each. Get a free API key and read the documentation to pin any leg by its airport.