Every eVTOL startup and drone-delivery company has the same problem sitting behind the vehicle engineering: they need to know what's already in the airspace they want to fly through. That means existing manned traffic, temporary flight restrictions, NOTAMs that close or constrain a corridor, and weather conditions at the altitudes where these vehicles operate — which is below 400 feet for most drones and below 3,000 feet for urban air mobility vehicles, a band that traditional aviation data covers poorly because manned aircraft are rarely there except on approach and departure.
This is a data-infrastructure problem more than a regulation problem. The FAA's UTM (Unmanned Traffic Management) framework and EASA's U-space concept both assume that operators will have real-time awareness of airspace conditions as a prerequisite for access. The question is where that awareness data comes from and how it gets into the vehicle's flight management system.
What AAM operators need to know
An advanced air mobility vehicle — whether it's a Joby air taxi or an Amazon delivery drone — needs to answer four questions continuously during a flight:
Is there manned traffic in or near my corridor? A drone operating at 300 feet AGL near an airport needs to know if a Cessna is on a practice approach through the same space. ADS-B gives you this, with one important caveat: not all GA aircraft are ADS-B equipped yet (the mandate covers rule airspace, not everywhere), so ADS-B alone doesn't guarantee a complete picture of manned traffic below 1,000 feet. But it's the best programmatic source available, and the coverage is good enough in terminal areas where AAM corridors are most likely to be established.
import requests
BASE = "https://skylink-api.p.rapidapi.com"
H = {"X-RapidAPI-Key": KEY, "X-RapidAPI-Host": "skylink-api.p.rapidapi.com"}
# Check for existing traffic in a potential UAM corridor
# (small bbox over a metro area, low altitude focus)
r = requests.get(f"{BASE}/adsb/aircraft", headers=H,
params={"bbox": "33.93,-118.43,34.10,-118.22"}) # LA basin
aircraft = r.json().get("aircraft", [])
low_altitude = [a for a in aircraft
if a.get("altitude") and a.get("altitude") < 3000
and not a.get("is_on_ground")]
print(f"Aircraft below 3000ft in corridor: {len(low_altitude)}")
for a in low_altitude:
print(f" {a.get('callsign','???'):8} alt={a.get('altitude')} "
f"gs={a.get('ground_speed')} type={a.get('aircraft_type','?')}")Are there active TFRs affecting my route? Temporary flight restrictions are the most common reason a drone flight gets a last-minute "no." A presidential TFR, a stadium TFR, a wildfire TFR — these pop up with varying amounts of notice and they're absolute constraints. A UAM routing engine needs to ingest active TFRs and reroute or hold when one conflicts with the planned path. The TFR endpoint provides active restrictions that can be checked against a planned route's coordinates.
Are there relevant NOTAMs? Beyond TFRs, NOTAMs carry other airspace restrictions — crane operations, construction near an airport, military exercises in specific blocks. A drone corridor that runs near an airport needs to monitor NOTAMs for that airport to catch restrictions that wouldn't show up as a TFR but still affect the usable airspace. The NOTAM API returns structured NOTAM data by airport or region.
# Check NOTAMs at airports near a planned drone corridor
r = requests.get(f"{BASE}/notams/KLAX", headers=H)
notams = r.json().get("data", [])
for n in notams[:5]:
print(f"NOTAM {n.get('id')}: {n.get('text', '')[:100]}")
print(f" Effective: {n.get('effective')} -> {n.get('expiry')}")What's the weather at my operating altitude? UAM vehicles are more weather-sensitive than airliners. A 25-knot crosswind at 500 feet AGL is a non-event for a 737 but a no-go for a light eVTOL. Surface METARs are a start, but they measure conditions at the airport's weather station, not at 300 feet over a vertiport three miles away. The aviation weather endpoint gives you the METAR, TAF, and winds aloft, which together provide a reasonable picture of low-altitude conditions.
The corridor concept and why it needs traffic data
Most AAM operational concepts are built around corridors — predefined paths through airspace that have been surveyed, deconflicted with existing traffic patterns, and approved by the relevant aviation authority. Think of them as highways in the sky, except the "road" is defined by coordinates and altitude bands rather than asphalt.
Defining a corridor requires knowing what traffic already uses that airspace. If your proposed corridor crosses the final approach path to runway 25L, it's going to conflict with manned traffic regularly, and the approval authority is going to reject it or impose restrictions that make it unusable during peak hours.
The data work for corridor planning looks like this:
-
Baseline traffic analysis. Pull position data for the proposed corridor area over a period of weeks or months. Count how many manned aircraft transit the corridor's altitude band and when. Identify the peak hours and the quiet windows. This is the analysis the authority will ask for when you submit the corridor proposal.
-
Approach and departure path mapping. Aircraft on instrument approaches follow published procedures with predictable lateral and vertical paths. Map these against the proposed corridor to identify conflicts. The approach fixes and altitudes are published, but the actual flown paths — which vary based on wind and ATC instructions — come from historical ADS-B data.
-
Ongoing monitoring. Once the corridor is approved and operational, you need real-time traffic awareness as an input to the deconfliction system. If a helicopter enters the corridor's lateral boundaries at an altitude that conflicts with a drone transit, the drone needs to know. ADS-B is the primary data source for this, supplemented by any ground-based radar or detect-and-avoid sensors the corridor operator installs.
# Historical traffic density analysis for corridor planning
# (simplified: poll once and count, real analysis uses weeks of data)
r = requests.get(f"{BASE}/adsb/aircraft", headers=H,
params={"bbox": "34.00,-118.30,34.05,-118.25"})
traffic = r.json().get("aircraft", [])
altitude_bands = {"0-500": 0, "500-1500": 0, "1500-3000": 0, "3000+": 0}
for a in traffic:
alt = a.get("altitude", 0)
if a.get("is_on_ground"):
continue
if alt < 500: altitude_bands["0-500"] += 1
elif alt < 1500: altitude_bands["500-1500"] += 1
elif alt < 3000: altitude_bands["1500-3000"] += 1
else: altitude_bands["3000+"] += 1
print("Traffic by altitude band:")
for band, count in altitude_bands.items():
print(f" {band} ft: {count} aircraft")The gap below 400 feet
Here's the honest limitation: ADS-B coverage below about 1,000 feet AGL is inconsistent. ADS-B is line-of-sight, and at very low altitudes, terrain and buildings block the signal from reaching receivers. In urban areas — exactly where UAM corridors will be — building shadowing is significant, and the coverage picture for a drone at 200 feet is substantially worse than for an aircraft at 5,000 feet.
This means ADS-B is good for answering "is there a manned aircraft on approach at 2,000 feet through my corridor?" but less reliable for "is there a news helicopter at 400 feet right now?" The detect-and-avoid systems on the AAM vehicles themselves will eventually handle the close-in problem, but the wide-area awareness layer — knowing about traffic 5 miles ahead — still depends on ADS-B and its coverage limits.
For corridor planning and pre-flight checks, this matters less. You're looking at patterns — how many aircraft typically transit this area at this altitude — and ADS-B captures the overwhelming majority of that traffic. For real-time conflict detection during flight, it's one input among several, and responsible operators will supplement it with onboard sensors and whatever traffic feeds the UTM service provider supplies.
UTM and the role of supplemental data services
The FAA's UTM concept and EASA's U-space both define a role for "supplemental data service providers" (SDSPs) — services that supply real-time information about airspace conditions, weather, and traffic to UAS operators. The data we're talking about in this post is exactly what an SDSP provides.
An SDSP needs to aggregate multiple data sources into a coherent picture:
- ADS-B for manned traffic awareness. This is the largest and most real-time feed available for knowing where manned aircraft are.
- TFRs and NOTAMs for airspace restrictions. Published data, but it needs to be ingested and continuously updated, not checked once before the flight.
- Weather for operational decisions. Surface observations and forecasts, updated frequently enough to catch fast-moving conditions. The weather endpoint with METAR and TAF data is the standard source.
- Terrain and obstacle data for route planning. This is typically static data, not something you'd get from a flight data API, but it's part of the SDSP picture.
The API integration pattern for an SDSP or a UAM operator building their own awareness layer is a combination of polling and event-driven checks:
- Poll the ADS-B bounding box for the corridor area every 5–10 seconds during active operations.
- Poll TFRs and NOTAMs every few minutes, or whenever a flight is being planned. The frequency depends on how dynamic the restrictions are — TFRs can appear with 30 minutes of notice, so checking only at pre-flight isn't sufficient for long-duration operations.
- Pull weather before each flight and at regular intervals during flight. METARs update roughly every hour, but special observations (SPECIs) can appear any time when conditions change rapidly.
The timeline and who's building this now
As of mid-2026, the companies building airspace-awareness infrastructure for AAM fall into three categories:
Vehicle OEMs (Joby, Archer, Lilium, Wisk, etc.) are building their own airspace-awareness modules as part of their flight management systems. They need data inputs, and they're evaluating which data providers to integrate with.
UTM/U-space service providers (Airbus UTM, OneSky, AirMap's successors) are building the platform layer that aggregates multiple data sources and provides a single API to operators. These companies are potential customers for raw data feeds, and they typically need higher-volume access than a single operator.
Drone-delivery operators (Wing, Zipline, Amazon Prime Air) are further along operationally and have mostly built custom airspace-awareness stacks already. Their needs are more about expanding coverage as they launch in new metros — each new delivery zone needs a traffic baseline and ongoing monitoring for the specific airspace.
All three categories need the same underlying data: traffic positions, airspace restrictions, and weather. The differentiation is in how they combine and present it.
Getting started
If you're building airspace awareness for a UAM corridor or drone operation, the relevant endpoints are ADS-B positions for traffic, NOTAMs and TFRs for restrictions, weather for conditions, and FAA delays for system-level disruptions that affect the airspace around you.
The free trial gives you enough requests to pull traffic data for a proposed corridor area and build the baseline analysis. For operational deployments polling continuously, you'll need a paid tier — the volume depends on how many corridor zones you monitor and at what interval.
For UTM service providers and vehicle OEMs integrating at scale, Enterprise is the path — it includes the SLA, the volume pricing, and the licensing terms your legal team will ask about.