← Journal Use case

Automate Hotel Airport Shuttles by Real Flight Arrival

Capture a guest's flight at booking and let FlightNerve drive your shuttle, front desk and housekeeping off real arrival times, not the printed schedule.

July 24, 2026 ·

· 13 min read

A guest books a suite for a Tuesday night and, in the notes field, types their flight number. By the time they land, their inbound flight has slipped 40 minutes, been reassigned to a different terminal, and their arrival now falls right at your evening check-in rush. Your shuttle, meanwhile, left the property on the printed schedule and is idling at the wrong door. This is the everyday gap between the flight a guest booked and the flight that actually lands — and it is exactly the gap you can close with software. This guide shows how to automate hotel airport shuttle by flight arrival using the FlightNerve real-time flight data API, so your front desk, housekeeping and drivers react to wheels-down reality instead of a schedule printed the day before.

The pattern is simple and it scales from a 40-room boutique to a resort running six shuttle loops an hour: capture the flight at booking, attach it to the reservation, let FlightNerve watch it, and let webhooks drive your operations. No one on staff refreshes a departures board. The API does the watching; your systems do the reacting.

Why schedule-based shuttle dispatch quietly costs you money

Hotel airport shuttles are usually run off two static inputs: the guest's stated arrival time and a fixed loop timetable. Both are wrong more often than operations teams admit. A flight listed to land at 18:05 may touch down at 17:41 or 18:49; the guest then waits at an empty pickup point or your driver burns a round trip for no one. Multiply an idle shuttle run — fuel, driver time, a vehicle out of rotation — across a week of inbound guests and the waste is real. The guest-experience cost is worse: the single worst first impression a property can make is a tired traveler standing curbside at 1 a.m. next to a shuttle that already left.

Guest arrival automation fixes this by making the flight itself the source of truth. Instead of a human transcribing "lands around 6," the reservation carries a structured flight (EK72) and date (20260726), and the property monitors it continuously. When the arrival estimate moves, the shuttle plan moves with it. That is the whole idea; the rest of this article is the mechanics.

Step 1 — Capture the flight at booking

Everything downstream depends on capturing a clean flight reference at reservation time. Add two fields to your booking flow or PMS: flight number and arrival date. A flight number is an airline code plus a number — EK72 is Emirates 72 — and FlightNerve accepts these as a name (the IATA airline code, e.g. EK) plus a num (the numeric part, e.g. 72). The date is YYYYMMDD.

Validate the flight the moment it is entered so you catch typos before the guest ever travels. One call to /airline confirms the flight exists and returns the arrival airport, terminal and scheduled time — data you can echo back to the guest as confirmation ("We'll meet EK72, arriving Terminal 3 at 18:05").

curl "https://api.flightnerve.com/airline/YOUR_KEY?num=72&name=EK&date=20260726"

const res = await fetch(
  "https://api.flightnerve.com/airline/YOUR_KEY?num=72&name=EK&date=20260726"
);
const flight = await res.json();
// flight.arrival.airportCode  -> "DXB"
// flight.arrival.scheduledTime, .estimatedTime, .terminal, .gate
// flight.aircraft.regNumber   -> tail number, e.g. "A6-ENV"
// flight.status               -> "Scheduled" | "Active" | "Landed" | ...

Each call costs one credit, and the free tier ships with 1,000 credits and no card, so validating every booking as it comes in is effectively free at boutique volumes. If the call returns a valid flight whose arrival.airportCode matches your local airport, attach it to the reservation and move on.

Step 2 — Read the real arrival time and terminal

The /airline response is the anchor for your shuttle plan. Two objects matter most: departure and arrival, each carrying scheduledTime, estimatedTime and, once available, actual times — all provided both as a local string and as ISO-8601 so you can do timezone-safe math. For a shuttle, the arrival object gives you the pickup point (terminal, gate, airportCode as IATA) and the ETA your dispatcher plans against.

Treat estimatedTime, not scheduledTime, as the number that drives dispatch. The scheduled time is a promise made months ago; the estimated time reflects the current trajectory. The status field — one of Scheduled, Active, Landed, Arrived, Delayed, Cancelled, Diverted — tells your desk which state to render on the day-of board: a "Delayed" flight gets a softened welcome window, a "Diverted" flight triggers a human phone call.

Step 3 — Let FlightNerve watch it: /monitor + webhooks

Polling /airline every few minutes for every inbound guest works, but it wastes credits and staff attention. The efficient pattern is to register the flight once and let FlightNerve push you changes. Post the flight to /monitor and you get back a stable monitoring_id that is echoed in every subsequent alert. Creating the monitor costs 1 credit, then 1 credit for each alert we deliver to your webhook, and you control how many by choosing which events matter and the sensitivity threshold. You never pay per check; you pay only when something actually changes.

curl -X POST "https://api.flightnerve.com/monitor/YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "flight": "EK72",
    "date": "20260726",
    "monitor": {
      "sensitivity_min": 20,
      "events": {
        "arrival_late": true,
        "arrival_early": true,
        "landed": true,
        "cancelled": true,
        "diverted": true,
        "gate": true,
        "terminal": true
      }
    }
  }'
// -> { "monitoring_id": "mon_fbba35cd573ca081" }

The sensitivity_min field is your noise filter: set to 20 and FlightNerve only re-alerts when an estimate moves by 20 minutes or more, so your dispatcher isn't paged over a three-minute wobble. Choose the events that map to a shuttle decision — arrival_late, arrival_early, landed, cancelled, diverted, plus gate/terminal so the driver goes to the right door. Other events (departure, baggage, schedule_change) are available if your workflow needs them.

Point FlightNerve at your endpoint once with /webhook, and every change to any monitored flight arrives as a JSON POST:

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

A delivered alert looks like this. Your handler responds with any 2xx to acknowledge, then routes the change to the right operation:

{
  "event": "flightnerve.alert",
  "alert_id": 481,
  "monitoring_id": "mon_fbba35cd573ca081",
  "flight": "EK72",
  "day": "20260726",
  "changes": [
    { "field": "arrival_estimate", "type": "delayed",
      "to": "2026-07-26T18:21:00Z", "to_local": "18:21", "delta_min": 34 }
  ]
}

The reservation's flight number flows through FlightNerve monitoring and a single webhook into your dispatch logic.

Step 4 — A single board for the day's inbound guests

Webhooks handle change events, but your front desk also wants a glanceable board of everyone arriving today. That is one call to /monitored, which returns your entire watchlist in a single response — every monitored flight that is scheduled, in the air, or landed within the last hour. Each entry carries status, regNumber, codeshares, the route ({from, to, fromCity, toCity}), and full departure/arrival blocks with scheduled, estimated, actual, delayMinutes, terminal, gate and baggage. When a flight is airborne it also includes live position — latitude, longitude, altitude, groundSpeed, heading, phase and progress.

import requests
board = requests.get(
    "https://api.flightnerve.com/monitored/YOUR_KEY"
).json()
for f in board:
    arr = f["arrival"]
    print(f["flight"], f["status"],
          "ETA", arr["estimated"], "delay", arr["delayMinutes"], "min",
          "T", arr["terminal"], "belt", arr["baggage"])

Render this on a back-office screen and your night manager sees, at a glance, which of tonight's fourteen inbound reservations are on time, which are delayed, and which have already landed and need a room ready. Pair it with /alerts (?unread=1) to keep a running change history for handover between shifts.

Step 5 — Stage the shuttle with a live inbound board

Knowing a flight is 34 minutes late tells you when to leave. Knowing exactly where it is in the descent tells you when to stage the vehicle. The /airspace endpoint with ?inbound=<airport> returns every airborne aircraft routed to your local airport, each with a distanceKm and an etaMinutes — a live inbound board you can filter to just your guests' tail numbers.

curl "https://api.flightnerve.com/airspace/YOUR_KEY?inbound=DXB"

Cross-reference the regNumber from your /monitored board against the inbound list, and when a guest's aircraft shows etaMinutes at, say, 18, your dispatcher launches the shuttle so it arrives just as bags hit the belt. No guessing, no idle curbside wait. For finer detail on a single airborne flight you can also call /track, which returns latitude, longitude, altitude, groundSpeed, heading, phase (climb/cruise/descent) and progress; it returns an empty array — and costs nothing — when the flight isn't airborne yet.

A worked example: EK72, delayed 40 minutes

Walk through a real evening. A guest is booked on EK72 on 2026-07-26, scheduled into DXB Terminal 3 at 18:05. Here is the timeline your automation runs, untouched by staff:

At booking: your PMS calls /airline?num=72&name=EK&date=20260726, confirms Terminal 3 / 18:05, and stores flight=EK72 on the reservation. It then POSTs to /monitor with sensitivity_min: 20 and gets back mon_fbba35cd573ca081. Cost so far: 2 credits (one lookup, one to arm the monitor); each alert it later delivers is 1 more.
Morning of: EK72 appears on the front desk's /monitored board as Scheduled, arrival 18:05, no delay.
16:50: the aircraft departs late. FlightNerve pushes a webhook — arrival_estimate, delayed, delta_min: 34, new local ETA 18:39. Because 34 > your 20-minute sensitivity, it fires. Your ops logic pushes the shuttle plan back and the guest gets an automatic SMS: "We're tracking EK72 — now arriving ~18:39, your driver will be there."
17:10: a second alert bumps the estimate to 18:45 (total ~40 late). Still one shuttle slot, just later — no idle run was ever dispatched against the original 18:05.
18:20: the flight is airborne on descent. It appears on /airspace?inbound=DXB at etaMinutes: 22. Dispatcher stages the shuttle.
18:44: a landed webhook fires. Housekeeping's "room ready" flag is already green; the front desk pre-keys the room; the shuttle is curbside at Terminal 3 arrivals as the guest clears the belt.

No one watched a departures screen. The property spent six credits, dispatched exactly one shuttle run at the right time, and turned a 40-minute delay into a seamless arrival.

Handling red-eyes, diversions and no-show waste

The same machinery earns its keep on the hard cases. Red-eye and delayed arrivals are where schedule-based dispatch fails worst — a 01:30 landing that slips to 02:40 means a driver either waits an extra hour or leaves and strands the guest. With a landed webhook you dispatch on wheels-down, not on a clock. Diversions are the scenario no timetable survives: when a flight is sent to another airport, the diverted status and event let you trigger a human call instead of sending a shuttle to an airport the guest will never reach. And cancellations — the biggest single source of no-show shuttle waste — arrive as a cancelled event, so the run is scrubbed and the room released or held per your policy, automatically.

The ROI: idle runs, staffing and welcome timing

Three cost lines move when you automate hotel airport shuttle by flight arrival. First, idle shuttle runs collapse: you dispatch against real ETAs, so vehicles stop making empty trips against a printed schedule. Second, front-desk staffing smooths out — a delayed batch of arrivals no longer all hits the desk at once, because your /monitored board shows the real spread across the evening and you staff to it. Third, welcome timing becomes precise: housekeeping prioritizes rooms for flights that are actually inbound, and the room is ready when the guest is, not two hours early or twenty minutes late. For a property running even a handful of airport pickups a night, cutting idle runs and no-show waits typically pays for the API many times over — and the guest-experience lift is the kind that shows up in reviews.

Getting started

You can wire the whole flow — capture, /airline validation, /monitor, one /webhook, a /monitored board and /airspace staging — against the free tier's 1,000 credits without a card. That's enough to run a real week of inbound guests end to end before you commit. Get a free API key to start, and see pricing when you're ready to scale to a full property. The integration is a few endpoints; the payoff is every guest met at the curb exactly when they land.

FAQ

How do I automate a hotel airport shuttle by flight arrival?

Capture the guest's flight number and date at booking, validate it with a /airline call, register it once with /monitor, and set a webhook. FlightNerve then pushes you every change — delays, early arrivals, gate/terminal moves and wheels-down — so your dispatcher launches the shuttle against the real arrival time instead of the printed schedule.

What flight information do I need to capture at booking?

Just two things: the flight number (an airline code plus number, e.g. EK72) and the arrival date in YYYYMMDD form. FlightNerve resolves the rest — arrival airport, terminal, gate, scheduled and estimated times, aircraft and tail number — from a single /airline lookup.

How do I avoid being paged over trivial one- or two-minute changes?

Set sensitivity_min in your /monitor request. It's the number of minutes a time estimate must move before FlightNerve re-alerts. A value of 20 means you only hear about changes that actually affect your shuttle plan, filtering out small in-flight fluctuations.

How does the system know when to physically stage the shuttle?

Use /airspace?inbound=<your airport>, which lists every airborne aircraft routed to that airport with a live distanceKm and etaMinutes. Match your guests' tail numbers (regNumber) against that board and dispatch when the ETA hits your drive-time window.

What happens if a guest's flight is cancelled or diverted?

Enable the cancelled and diverted events on the monitor. A cancellation scrubs the shuttle run and lets you release or hold the room automatically; a diversion fires a distinct event so you can trigger a human follow-up instead of sending a vehicle to the wrong airport.

Do I have to poll the API for every flight?

No. Register each flight once with /monitor and point a single webhook at your server; FlightNerve pushes changes to you. For a glanceable day-of view, one call to /monitored returns the whole watchlist — scheduled, airborne and recently landed — in a single response.

What does it cost to monitor a flight?

A single lookup is one credit; monitoring a flight is five credits for its entire lifecycle, no matter how many times it re-alerts. The free tier includes 1,000 credits with no card, enough to run a full week of inbound guests. See pricing to scale up, or get a free API key to begin.

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