← Journal Use case

Duty of Care: Real-Time Flight Tracking for Corporate Travel

Build duty of care flight tracking on FlightNerve: watch every employee itinerary, run one live board, and get webhook alerts on delays and diversions.

July 24, 2026 ·

· 11 min read

When an employer puts staff on aircraft, it takes on a responsibility that does not end at the departure gate. Duty of care flight tracking is the practice of knowing where your travelling employees are in the air, in real time, and being able to react the moment a flight is delayed, diverted or cancelled. It is part legal obligation, part moral one, and increasingly a board-level expectation for any organisation with a mobile workforce. This guide shows how to build that capability on the FlightNerve API: feeding every itinerary into a watchlist, rendering a single duty-manager board of all in-air and upcoming employee flights, alerting the travel and security desk on disruption, and drilling into one traveller's live position during an incident.

The distinction that matters throughout is between a disruption dashboard — a screen someone occasionally glances at — and true real-time awareness, where the system itself pushes a change to the people who need to act on it. A robust corporate travel flight monitoring API programme delivers both: a board you can pull on demand, and events that arrive without anyone asking.

Why duty of care flight tracking is a legal and operational requirement

Under health-and-safety and travel-risk-management frameworks in most jurisdictions, an employer must take reasonable steps to protect employees while they travel for work. In practice that means three things: knowing an employee's whereabouts to a useful resolution, being able to reach them, and being able to respond when something goes wrong. A flight is the segment of a trip where the traveller is least reachable and most exposed to sudden change — a diversion can move someone 800km from their planned destination in under an hour, into a country that was never on the itinerary.

Traveller tracking for travel risk management therefore hinges on flight state. If your security operations centre learns about a diversion from the news rather than from a system, your duty-of-care posture has already failed. The goal is to make the flight itself an event source: every status transition — Scheduled, In Air, Arrived, Diverted, Cancelled — becomes a signal your platform can reason about.

Feeding every itinerary into the watchlist

The foundation is a watchlist that mirrors your live population of travelling staff. Each time a booking is confirmed — from your TMC feed, GDS, or expense system — you push that flight into FlightNerve. There are two complementary ways to do it.

Use /watch to simply add a flight to the board so it appears in your duty-manager view. Use /monitor when you also want proactive event alerts for that specific segment (covered below). Most duty-of-care platforms call both: /watch for board visibility on every leg, and /monitor for the legs that warrant active paging.

# Add a confirmed itinerary leg to the watchlist
curl -X POST https://api.flightnerve.com/watch/YOUR_KEY \
  -H "Content-Type: application/json" \
  -d '{"flight":"BA249","date":"20260726"}'

# Node — add each leg of a traveller's itinerary as bookings land
const legs = [
  { flight: "BA249", date: "20260726" },
  { flight: "LA8084", date: "20260726" }
];

for (const leg of legs) {
  await fetch("https://api.flightnerve.com/watch/YOUR_KEY", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(leg)
  });
}

When a trip completes or is cancelled in your booking system, remove the leg so the board stays clean: {"action":"remove","id":42} to the same endpoint. The API automatically drops flights that landed more than an hour ago, so short-lived clutter takes care of itself — but explicit removal of cancelled bookings keeps your population count honest.

One board for the whole travelling workforce

The single most valuable call for a duty manager is /monitored. One request returns a live board of your entire watchlist: every flight that is scheduled or currently airborne, plus anything that landed within the last hour. No pagination, no per-flight polling — the state of your whole travelling population in a single response.

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

# Python — render the duty-manager board
import requests

board = requests.get("https://api.flightnerve.com/monitored/YOUR_KEY").json()

for f in board["flights"]:
    line = f'{f["flight"]}  {f["route"]["fromCity"]} -> {f["route"]["toCity"]}  {f["status"]}'
    if f["status"] == "In Air":
        p = f["position"]
        line += f'  ({p["progress"]}% | {p["altitude"]}ft | {p["groundSpeed"]}kt)'
    dep = f["departure"]
    if dep.get("delayMinutes"):
        line += f'  DELAY +{dep["delayMinutes"]}m'
    print(line)

Each flight on the board carries everything a duty desk needs at a glance: status, regNumber, any codeshares, the full route with city names, departure and arrival blocks (scheduled, estimated and actual times in ISO-8601 UTC, plus delayMinutes, terminal, gate and baggage), and — when airborne — a position object with latitude, longitude, altitude, ground speed, heading, flight phase and progress. This is the difference between a spreadsheet of bookings and an operations picture. One call, one credit, the whole board.

Alerting the travel and security desk on disruption

A board tells you the current state when you look at it. Duty of care demands that the system tell you when something changes. That is what /monitor plus webhooks provide. When you register a leg for monitoring you set a sensitivity threshold and choose which events matter.

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

The call returns a stable monitoring_id that is echoed in every subsequent webhook, so you can correlate alerts back to a specific traveller and trip in your own database. Register one webhook endpoint per account with /webhook:

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

From then on, FlightNerve POSTs a compact payload whenever a monitored flight changes. The full event vocabulary covers departure, departure_late, departure_early, arrival_late, arrival_early, gate, terminal, baggage, schedule_change, cancelled, diverted and landed. Your endpoint simply needs to respond with any 2xx status.

{
  "event": "flightnerve.alert",
  "monitoring_id": "mon_7f3a9c",
  "flight": "BA249",
  "day": "20260726",
  "changes": [
    { "field": "status", "type": "diverted" }
  ]
}

Note the pricing model: creating a monitor costs 1 credit, then 1 credit per alert delivered to your webhook, while board pulls and lookups are 1 credit each. Because you only pay for alerts that fire, and you choose which events and how sensitive, it stays economical to monitor every leg of every trip. See pricing for volume tiers, and you can start on the free tier of 1,000 credits with no card via get a free API key.

Drilling into one traveller's live position during an incident

When an alert fires, the duty manager needs to move from the population view to a single flight fast. The /track endpoint returns the live position of one specific airborne flight — latitude, longitude, altitude, ground speed, heading, phase, progress, source and registration.

curl "https://api.flightnerve.com/track/YOUR_KEY?num=249&name=BA"

# Node — pull live position for the incident flight
const res = await fetch(
  "https://api.flightnerve.com/track/YOUR_KEY?num=249&name=BA"
);
const pos = await res.json();
console.log(`${pos.latitude},${pos.longitude} @ ${pos.altitude}ft, ${pos.progress}% complete`);

During a live diversion this lets a security analyst watch the aircraft's actual track toward its new destination, estimate a landing airport, and brief a local response before the flight is even on the ground. Paired with /alerts — which returns the change history newest-first, filterable with ?unread=1 — you have both the timeline of what happened and the live picture of what is happening now.

Building an escalation workflow

Real-time awareness is only useful if it reaches a human who can act. The webhook is the trigger; your escalation logic decides who gets paged and how loudly. A workable pattern:

Informational events (departure, gate, terminal, baggage, landed) update the traveller record and the board silently — no page.
Disruption events (departure_late, arrival_late beyond your sensitivity_min, schedule_change) notify the travel desk during business hours and log for the morning report otherwise.
Critical events (cancelled, diverted) page the on-call duty manager immediately, 24/7, and open an incident record keyed by monitoring_id.

Because the monitoring_id is stable across the flight's life, your incident system can attach every subsequent change — the diversion, then the eventual landed — to the same case, giving a clean audit trail of when you knew and how you responded. That trail is exactly what a duty-of-care review will ask for after the fact.

Privacy and data minimisation

Employee tracking carries obligations of its own. The strength of flight-based duty of care is that it is inherently data-minimising: you track the flight, not the person's every movement. You know a traveller is on BA249 and where that aircraft is; you are not following their phone through a city. This is a defensible position under most privacy regimes and worth stating explicitly in your travel policy.

Good practice: monitor a leg only while it is active, remove flights from the watchlist once trips complete, store the monitoring_id rather than duplicating personal itinerary detail where you can avoid it, and restrict board access to the duty and security roles that need it. The API's automatic drop-off of flights landed more than an hour ago aligns neatly with retaining live-tracking data only as long as it serves a purpose.

Worked example: a diversion, end to end

Consider BA249, London Heathrow to São Paulo, carrying two engineers. Both legs are in the watchlist via /watch, and the long-haul leg is registered with /monitor (events: diverted, cancelled, arrival_late, landed).

T+0 — A medical situation forces the aircraft to divert to Recife. FlightNerve detects the status change and POSTs a webhook: {"changes":[{"field":"status","type":"diverted"}]} with monitoring_id: mon_7f3a9c.
T+5s — Your escalation layer classifies diverted as critical, opens incident INC-4471 against the two travellers, and pages the on-call duty manager.
T+20s — The duty manager opens the board via /monitored; the flight now shows Diverted with a live position tracking north-east toward Recife.
T+1m — Using /track, the security desk confirms the aircraft's heading and progress, identifies Recife as the likely landing point, and alerts the regional response contact and the travellers' next-of-kin protocol.
T+40m — A landed webhook arrives on the same monitoring_id; the incident is updated, ground support is dispatched, and rebooking begins.

At no point did anyone need to refresh a page hoping to catch the change. The system did the watching; the humans did the responding. That is the operating definition of duty of care flight tracking, and it is what separates a corporate travel flight monitoring API programme from a passive dashboard.

FAQ

What is duty of care flight tracking?

It is the practice of monitoring employees' flights in real time so an employer can meet its legal and moral obligation to know where travelling staff are and respond to disruption. With FlightNerve it means feeding itineraries into a watchlist, watching a live board via /monitored, and receiving webhook alerts on delays, diversions and cancellations.

How do I track all my travelling employees at once?

Add every booked leg to your watchlist, then call /monitored. A single request returns every flight that is scheduled or airborne, plus anything landed in the last hour, with status, route, times and live position — the whole travelling population in one response for one credit.

How does the corporate travel flight monitoring API alert us to a diversion?

Register the leg with /monitor and set a webhook via /webhook. When the flight's status changes to diverted, FlightNerve POSTs an event with a stable monitoring_id so your escalation workflow can page the duty desk and open an incident automatically. See /alerts for the change history.

Can I see exactly where an employee's flight is right now?

Yes. Call /track with the flight number and airline code to get live latitude, longitude, altitude, ground speed, heading, phase and progress for that specific airborne flight — ideal for briefing a response during an active incident.

Does traveller tracking raise privacy concerns?

Flight-based tracking is data-minimising by design: you follow the flight, not the individual's every movement. Monitor legs only while active, remove completed trips from the watchlist, and restrict board access to duty and security roles. This keeps travel risk management proportionate and defensible.

How much does it cost to get started?

The free tier includes 1,000 credits with no card required. Board pulls and lookups cost 1 credit; creating a monitor costs 1 credit, then 1 credit per delivered webhook alert. You can get a free API key and review pricing for higher volumes.

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