← Journal Use case

Track VIP & Speaker Flight Arrivals for Events

Build a live arrivals board for your event ops room, alert greeters and drivers per VIP, and re-sequence the run-of-show when a keynote's flight slips.

July 24, 2026 ·

· 13 min read

A summit is a room full of people who all had to fly in. On the morning of day one, your keynote is somewhere over the Atlantic, three panelists are connecting through a hub, two sponsors are on a red-eye, and the minister who opens the plenary is on a government charter that never appears on a public timetable the way a scheduled airline does. Your job is to make every one of them walk on stage rested, on time, and convinced the logistics were effortless. To track VIP flight arrivals for an event, you need a single source of truth for who is landing when — and it has to update itself, because no ops lead has time to refresh two dozen airline pages while also holding a run-of-show together. This guide shows how to build that source of truth with the FlightNerve real-time flight data API: a live arrivals board for the ops room, greeter and driver alerts per VIP, and the FlightNerve Estimated Arrival as your "when will they really land" anchor.

The model is the same whether you run a 60-person executive retreat or a 5,000-delegate conference across three hotels: capture every inbound flight into a watchlist, power one arrivals wall from a single API call, and let webhooks fire the exact people who need to move — the greeter at the gate, the driver in the car park, the green-room stage manager. The API does the watching. Your team does the hosting.

Why event guest flight tracking beats a shared spreadsheet

Most VIP arrival tracking still lives in a spreadsheet: a column for name, a column for flight, a column for "lands ~14:00" typed in by whoever built the roster. That spreadsheet is wrong the moment a single flight slips, and on a multi-speaker day something always slips. The failure modes are predictable and expensive. A greeter stands at the wrong terminal because the inbound was reassigned. A chauffeur completes a round trip for a delegate who is still airborne. A keynote's car is dispatched on the scheduled time, sits in a taxi rank for 50 minutes, and the speaker walks out to no name-board because the driver gave up and re-parked. Worst of all, the run-of-show does not adjust, and you discover the keynote is not in the building ninety seconds before they are due on stage.

Conference logistics flight monitoring fixes this by making the flight itself the record. Instead of a human transcribing "lands around two," the roster carries a structured flight (AF1180) and date (20260926), and FlightNerve watches it continuously. When an arrival estimate moves, every downstream decision — greeter timing, car dispatch, green-room call — moves with it. The rest of this article is the mechanics of getting there.

Step 1 — Build the speaker roster into a watchlist

Start by turning your VIP roster into a FlightNerve watchlist. For each person's inbound flight, POST once to /watch with the flight number and arrival date. The watchlist is your master list of everyone the event cares about, and it persists across the run of the event.

curl -X POST "https://api.flightnerve.com/watch/YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"flight":"AF1180","date":"20260926"}'

import requests

roster = [
    {"name": "Keynote — Dr. Meline",  "flight": "AF1180", "date": "20260926"},
    {"name": "Panelist — R. Okoro",   "flight": "BA246",  "date": "20260926"},
    {"name": "Title sponsor — Vanté", "flight": "LH400",  "date": "20260926"},
]

for guest in roster:
    requests.post(
        "https://api.flightnerve.com/watch/YOUR_KEY",
        json={"flight": guest["flight"], "date": guest["date"]},
    )

Keep your own mapping of flight number to person, role, hotel and assigned greeter — FlightNerve tracks the aircraft, you track the human. A quick GET on /watch returns every tracked flight with three arrival anchors side by side: scheduled_utc (the airline's promise), fn_estimated_utc (the FlightNerve Estimated Arrival), and live_utc (a live figure once the aircraft is airborne), plus cancelled, diverted and arrived flags. To drop someone who cancelled, POST {"action":"remove","id":42} with the id from the list. Adding a flight to your watchlist is one credit; the continuous monitoring you attach in Step 3 is billed separately and flat.

The three arrival anchors, and which one to trust

Speaker arrival tracking lives or dies on the ETA you plan against, so understand the three anchors. scheduled_utc is what was published months ago — useful only as a reference. live_utc exists once the flight is in the air and reflects the current trajectory. The FlightNerve Estimated Arrival (fn_estimated_utc) is the one to build your greeter and car timing on: it is FlightNerve's own projection of when the aircraft will actually be on the ground, available before departure and refined all the way to wheels-down. When a driver asks "when do I leave for the airport," you answer from fn_estimated_utc, not the ticket.

Step 2 — One call powers the ops-room arrivals wall

The centerpiece of event guest flight tracking is a live arrivals wall in the ops room: a screen that shows, at a glance, who is still to land, who is in the air, each ETA, terminal, and a red flag on anyone running late. You do not build that from many calls. You build it from one. GET /monitored returns the live board of everything on your watchlist that still matters — scheduled, airborne, or landed within the last hour — and drops the rest, so the wall stays focused on the flights your team can still act on.

curl "https://api.flightnerve.com/monitored/YOUR_KEY"

const res = await fetch("https://api.flightnerve.com/monitored/YOUR_KEY");
const board = await res.json();

for (const f of board.flights) {
  console.log(
    f.flight,                    // "AF1180"
    f.status,                    // "Active" | "Landed" | "Delayed" ...
    f.route.fromCity, "->", f.route.toCity,
    f.arrival.estimated,         // ETA to plan against
    f.arrival.delayMinutes,      // e.g. 50
    f.arrival.terminal, f.arrival.gate,
    f.regNumber                  // tail, e.g. "F-HPJD"
  );
}

Each flight on the board carries everything an arrivals wall needs: status, regNumber, any codeshares, a route object (from, to, fromCity, toCity), and departure/arrival objects with scheduled, actual, estimated, delayMinutes, terminal, gate and baggage. When a flight is airborne it also carries live position, so your wall can show a map dot creeping toward the field. Poll /monitored on a comfortable cadence — every 60 to 120 seconds is plenty for a room screen — and render the whole VIP arrivals board from that single response. This is the exact shape of data a green-room or VIP arrivals board wants: one request in, one board out.

Step 3 — Alert greeters and drivers per VIP

The arrivals wall keeps the ops room informed, but your greeters and drivers are at the airport, not staring at a screen. For VIP transfer coordination you want a push, not a poll: the moment a specific VIP's flight lands, is running late, or changes terminal, the right handler's phone should buzz. Register each roster flight with /monitor, choosing exactly the events that map to a physical action.

curl -X POST "https://api.flightnerve.com/monitor/YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "flight": "AF1180",
    "date": "20260926",
    "monitor": {
      "events": {
        "arrival_late": true,
        "landed": true,
        "gate": true,
        "cancelled": true,
        "diverted": true
      }
    }
  }'

Creating the monitor costs 1 credit, then 1 credit for each alert we deliver to your webhook, and you decide how many by subscribing only to the events that trigger a move on your end. A keynote you watch from the day before through wheels-down might fire a handful of alerts, and you pay only for those, never per check. The call returns a stable monitoring_id echoed in every alert, which you map back to the person. FlightNerve exposes a rich event set — departure, departure_late, departure_early, arrival_late, arrival_early, gate, terminal, baggage, schedule_change, cancelled, diverted, landed — so subscribe only to the ones that trigger a move on your end and keep the noise down.

Point FlightNerve at your endpoint once with /webhook, and every change is pushed to you as JSON. Respond 2xx and you are done.

curl -X POST "https://api.flightnerve.com/webhook/YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://ops.yoursummit.com/hooks/flightnerve"}'

# FlightNerve POSTs this to your endpoint on any change:
{
  "event": "flightnerve.alert",
  "monitoring_id": "mon_9f21a7",
  "flight": "AF1180",
  "day": "20260926",
  "changes": [
    {"type": "arrival_late", "delayMinutes": 50, "estimated": "14:50"},
    {"type": "terminal", "from": "2E", "to": "2F"}
  ]
}

In your handler, look up monitoring_id, find the person and their assigned greeter and driver, and route the change: an arrival_late holds the car and pushes the green-room call; a terminal change texts the greeter a new meet point; a landed event tells the driver to pull to the curb. If you would rather pull a change history than run an endpoint — for a mid-event audit, or to reconcile after the fact — GET /alerts?unread=1 returns everything that has fired.

The exact greet point: /airline per VIP

A name-board in the wrong hall is a missed VIP. When a greeter needs the precise meet point for one speaker, hit /airline for that flight and read the arrival terminal and gate directly.

curl "https://api.flightnerve.com/airline/YOUR_KEY?num=1180&name=AF&date=20260926"

The response carries the arrival terminal and gate so your greeter stands at the right door with the right board, and the driver knows which pickup lane to circle. For a speaker meet, that single call closes the last hundred meters between "the flight landed" and "we have eyes on our VIP."

Worked example — a keynote slips 50 minutes

Day one. Your keynote, Dr. Meline, is inbound on AF1180, scheduled to land 14:00, due on the main stage at 16:30 after a green-room briefing at 15:45. The flight is on your watchlist and monitored for arrival_late, terminal and landed.

12:10 — the slip. The aircraft departs late. FlightNerve pushes an arrival_late change: delayMinutes: 50, new estimated arrival 14:50. Your ops-room arrivals wall, reading /monitored, flips Dr. Meline's row red and shows the new ETA off the FlightNerve Estimated Arrival.
12:11 — cars and greeter held. Your webhook handler maps mon_9f21a7 to Dr. Meline, and messages the assigned driver — "hold, new ETA 14:50, do not depart until 14:05" — and the greeter, who now knows not to stand at arrivals for an hour.
12:15 — the program re-sequences. The stage manager sees the red row and swaps the run-of-show: the sponsor panel, whose speaker is already in the building, moves up to 16:15, and the keynote shifts to the 16:45 slot. A single flight event just protected the whole afternoon.
14:52 — landed. FlightNerve fires landed. The driver, already curbside from the held ETA, pulls in. The greeter, holding the board at the terminal confirmed by /airline, has eyes on Dr. Meline within minutes of the doors opening.
15:40 — green room. Dr. Meline is in the building, briefed, and walks on at 16:45 to a full room. No one in the audience knew the flight was ever late.

That is the entire value of speaker arrival tracking in one sequence: the delay was known the instant it happened, the physical resources moved before anyone waited, and the program adjusted with hours of runway instead of seconds.

Multi-day, multi-airport, multi-VIP

Real events are not one arrival day. Delegates trickle in across a pre-event build, sponsors arrive the night before, and speakers land on the morning of their session — sometimes into different airports if the city has more than one field, or across satellite venues in a city-wide congress. The watchlist model handles all of it without new plumbing: every inbound flight, whatever its day or destination, goes onto the same /watch list, and /monitored always returns just the flights that currently matter — today's arrivals and anyone landed within the last hour — while automatically dropping yesterday's. Your arrivals wall on day three shows day-three people. Filter the /monitored response by arrival airport in your own code and you can drive a separate board per terminal team, all from the one call.

For protocol and VIP-handling teams juggling tiers of guests — heads of delegation, keynote speakers, title sponsors, general delegates — the monitoring_id mapping is where your priority logic lives. A landed event for a head of delegation might page a senior protocol officer and hold a dedicated car; the same event for a general delegate might simply mark them present in your check-in system. FlightNerve gives you the flight truth; your handler decides how loudly each person's arrival rings.

Getting started

You can stand up a working VIP arrivals board before your next production meeting. Get a free API key — the free tier ships with 1,000 credits and no card, which is enough to watch and monitor a full roster of speakers through a multi-day event. Add each flight with /watch, render your wall from /monitored, wire greeter and driver alerts through /monitor and webhooks, and confirm meet points with /airline. When your event calendar outgrows the free tier, the pricing scales with the number of arrivals you track, not the number of times you check them.

FAQ

How do I track VIP flight arrivals for a conference with dozens of speakers?

Add each speaker's inbound flight to a FlightNerve watchlist with /watch, then power a single ops-room arrivals wall from one /monitored call that returns live status, ETA, terminal and delay flags for everyone still to land. Keep your own map of flight number to person so FlightNerve tracks the aircraft while you track the VIP.

Which arrival time should I use to schedule greeters and cars?

Use the FlightNerve Estimated Arrival (fn_estimated_utc), not the airline's scheduled time. It is FlightNerve's own projection of when the aircraft will actually be on the ground, available before departure and refined to wheels-down, so it is the right number for VIP transfer coordination and green-room timing.

How do greeters and drivers get notified when a specific VIP lands?

Register each flight with /monitor, subscribe to events like landed, arrival_late and terminal, and register a /webhook endpoint. FlightNerve POSTs a JSON alert with a stable monitoring_id on every change; your handler maps it to the person and pages the right greeter and driver.

How do I find the exact terminal and gate to meet a speaker?

Call /airline for that flight and read the arrival terminal and gate from the response. That gives your greeter the precise meet point and your driver the right pickup lane, closing the last gap between "the flight landed" and "we have the VIP."

Does this work across multiple days and multiple airports?

Yes. Every inbound flight goes on the same watchlist regardless of day or destination, and /monitored always returns just the flights that currently matter — today's arrivals and anyone landed within the last hour. Filter the response by arrival airport in your own code to drive a separate board per terminal or venue team.

What does conference logistics flight monitoring cost?

Adding a flight to your watchlist is one credit, and monitoring a flight is five credits for its entire lifecycle — not per check — so a heavily re-alerting keynote still costs five credits total. The free tier includes 1,000 credits with no card; see pricing to scale up for larger event calendars.

Build it in minutes — free to start.Get an API key →