← Journal Guide

Handling Diverted and Cancelled Flights in Your App

Disruptions are where flight-driven products earn or lose trust. Here is how to detect a cancellation or a diversion from the API — including the airport a diverted flight actually reached — and exactly how to react.

August 2, 2026 · · 4 min read

Most flight integrations are built for the happy path: the flight departs, flies, and lands where it said it would. The value of good flight data shows up on the unhappy path — when a flight is cancelled, or diverts to a different airport. Those are the moments a passenger is stranded, a driver is at the wrong terminal, or a shipment misses its window. This guide shows how to detect both from the API and, more importantly, what to do the moment you see them.

Two disruptions, two fields

Every flight response carries its disposition, so you never have to infer it from times. Two boolean flags and a status string tell you what happened:

Flight response flightStatus · cancelled · diverted cancelled: true notify the traveller · stop the pickup start rebooking / refund diverted: true → diverted_to redispatch to the new airport move the transfer · reset the ETA
A cancellation and a diversion need different responses — and a diversion needs the airport the flight actually reached.

Detecting a cancellation

Ask for the flight and check the flag. A cancelled flight still resolves — you get the flight back, flagged — so you can react without special-casing an error.

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

 [
  {
    "origin":      { "iata": "DXB" },
    "destination": { "iata": "MUC" },
    "flightStatus": "Cancelled",
    "cancelled": true,
    "diverted": false
  }
]

What to do: stop any pickup or transfer tied to this flight, notify the traveller immediately, and kick off your rebooking or refund flow. The earlier you catch it, the more options everyone still has — a cancellation you surface hours ahead is a rebooking; one you surface at the curb is a complaint.

Detecting a diversion — and where it went

A diversion is trickier than a cancellation, because the flight is arriving — just not where anyone planned. A status-only view leaves you knowing the flight "diverted" but not to where, which is useless for a pickup. The response names the airport it actually reached in diverted_to:

 [
  {
    "origin":      { "iata": "JFK" },
    "destination": { "iata": "BOS" },
    "flightStatus": "Diverted",
    "diverted": true,
    "diverted_to": "PVD"
  }
]

What to do: treat diverted_to as the new arrival airport. Redispatch the driver there, move the transfer, and reset the arrival ETA against the new destination. For a passenger, that is the difference between a car waiting at Providence and a car idling at Boston while the traveller lands 80 km away.

React the instant it happens — don't poll for it

Cancellations and diversions are exactly the events you cannot afford to catch on your next poll. Create a monitor for the flight and both are delivered to your webhook the moment they are known, alongside delays, gate changes and landing:

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

Each alert carries the monitoring_id you got when you created the monitor, so you can map it straight back to the booking, pickup or shipment it affects and run the right playbook automatically.

A simple decision table

Frequently asked questions

Does a cancelled flight return an error?

No. It resolves normally with cancelled: true and flightStatus: "Cancelled", so you handle it as data, not as a failed request.

How do I know which airport a diverted flight landed at?

The diverted_to field names it. Use that as the real arrival airport for any pickup, transfer or connection logic.

Can I be alerted on cancellations and diversions instead of checking?

Yes — a monitor delivers both to your webhook the moment they are known, so your system reacts without anyone watching a screen.

What is the difference between diverted and cancelled for my workflow?

A cancellation means the trip isn't happening — notify and rebook. A diversion means it is happening, elsewhere — move your ground plan to diverted_to and keep going.

Will the arrival times update after a diversion?

Treat the arrival against the new destination: reset your ETA logic to diverted_to rather than the original planned airport.

Disruptions are the moments your integration proves its worth. Read cancelled and diverted on every flight, use diverted_to to send people to the right airport, and let monitoring push both to you the instant they happen — so a bad day for the airline isn't a bad day for your customer.

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