A Temporary Flight Restriction — a TFR — is a chunk of airspace the FAA closes off for a limited time, for reasons ranging from a wildfire to a presidential visit to a rocket launch. Bust one and you can expect an intercept and a very bad day. For anyone building flight-planning tools, EFB apps, or drone software, TFRs are a hard operational constraint you can't ignore — and, awkwardly, one that doesn't come from a tidy dedicated endpoint. This post explains what TFRs are, how they're defined and published, and how to actually check for them by API.

What a TFR actually is

A TFR restricts flight in a defined volume of airspace, for a defined window of time, usually because something on the ground or in the air makes normal traffic unsafe or unwanted. Each one specifies a center point, a radius, a floor and ceiling altitude, an effective start and end time, and a reason. Outside those bounds it doesn't apply; inside them, only specifically authorized aircraft may operate.

TFRs are a US construct issued by the FAA (other countries have equivalents under different names). The common reasons cluster into a few buckets:

  • Security / VIP movement — "presidential" TFRs around the movement of senior officials are the largest and most tightly enforced.
  • Hazards and disasters — wildfires, chemical spills, floods. These protect firefighting aircraft and keep sightseers out.
  • Special events — large stadiums during major sporting events get standing TFRs on game days.
  • Space operations — launches and reentries close airspace along the corridor.

An aircraft dropping water over a wildfire, the kind of hazard that triggers a firefighting TFR

How TFRs are published (and why there's no simple "TFR API")

Here's the part that surprises developers: a TFR is not its own data type. It's published as a NOTAM — specifically an FDC (Flight Data Center) NOTAM, the regulatory class of notice. The FAA maintains a human-facing list at tfr.faa.gov, but the machine-readable source of truth is the NOTAM system. So "checking TFRs by API" really means pulling NOTAMs and identifying the ones that are restrictions.

That's a feature, not a bug: because TFRs live in the NOTAM stream, the same call that surfaces a closed runway or an unserviceable approach also surfaces the airspace restriction over the field.

Checking for TFRs by API

The practical path is the NOTAMs endpoint, which returns active notices for an airport. TFR-relevant NOTAMs show up here, and you filter for them client-side:

curl "https://skylink-api.p.rapidapi.com/notams/KJFK" \
  -H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
  -H "X-RapidAPI-Host: skylink-api.p.rapidapi.com"

Each entry carries the raw NOTAM text, identifiers, effective/expiration times (in UTC), and a scope. Restriction notices typically carry airspace scope and FDC-style identifiers, and the body spells out the restricted area and reason — so you scan the notams array for those markers rather than expecting a boolean is_tfr field.

For a route rather than a single airport, generate a preflight briefing. It assembles weather and NOTAMs for an origin–destination pair and surfaces high-priority constraints in a critical_restrictions field, which is the fastest way to flag route-affecting restrictions without parsing every NOTAM yourself:

curl "https://skylink-api.p.rapidapi.com/briefing/flight?origin=KLAX&destination=KJFK" \
  -H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
  -H "X-RapidAPI-Host: skylink-api.p.rapidapi.com"

An aerial view of a packed stadium crowd, the kind of major event that gets a standing TFR

Three things to build in from the start

  • US-centric. TFRs are FAA notices covering US airspace. For other countries you're looking at their national NOTAM equivalents, not "TFRs" by that name.
  • Empty is normal. No active notices for an airport returns a 200 with an empty notams array — a fair-weather answer, not an error. Don't treat it as a failure.
  • Assistive, not authoritative. An API briefing is a decision aid, not a legal dispatch release. For a go/no-go decision, verify against the official FAA source and show a visible disclaimer in any pilot-facing UI — TFRs change and are amended, and the regulatory source is the one that counts.

Where TFRs fit in a briefing stack

TFRs are one layer of the pre-flight picture: pair the NOTAM-derived restrictions with decoded weather, en-route SIGMETs and AIRMETs, and full NOTAM search, and you can draw the whole hazard-and-restriction map for a flight. The restriction is airspace you must route around; the rest is weather you must plan for.

SkyLink API gives you a free tier of 1,000 requests/month to pull NOTAMs and briefings against, with paid plans starting at $19/mo for production traffic. It's available through the free trial — sign up, grab a key, and surface temporary flight restrictions before they surprise a flight.