What CPDLC Is, and the Problem It Solves
For most of aviation history, a controller and a pilot coordinated one way: by voice, over a VHF radio channel. That works, but it has hard limits. A single frequency can only carry one conversation at a time, so busy sectors saturate; instructions can be misheard and read back wrong; and over oceans and remote regions there is often no VHF ground coverage at all, which historically meant slow, crackly HF voice relays.
CPDLC replaces those spoken exchanges with structured text. A controller sends a clearance — a new level, a heading, a route amendment — as a datalink message; the pilot reads it on a cockpit display and answers with a single tap: WILCO, UNABLE or ROGER. The channel is no longer a shared open microphone but a set of addressed messages between one aircraft and one control centre.
If you have read our guides on ACARS, HFDL and VDL, you have already met the pipes that make this possible. CPDLC is not a new radio — it is the air-traffic-control application that travels over those existing datalinks. And that distinction matters for anyone working with flight data, because CPDLC itself is a private cockpit-to-controller channel. What a flight tracker sees is never the message — it is the movement the message produces.
"Voice is being quietly replaced by text in the busiest and emptiest airspace alike. But a flight data feed never carries the clearance — it carries its consequence: the pushback that happened on time, the ocean track the aircraft was moved onto, the arrival that held its slot."
How a CPDLC Exchange Works
Before any messages flow, the aircraft has to log on to the controlling unit. This connection step — the Data Link Initiation Capability (DLIC), handled by the Context Management (CM) application — tells the ground system which aircraft it is talking to and establishes the data session. Only once logon succeeds can clearances be exchanged.
From there, messages move in two directions: uplinks from controller to pilot, and downlinks from pilot to controller. They fall into a defined set of applications — ATC Clearance (ACL) for the clearances and requests themselves, ATC Communications Management (ACM) for handing an aircraft between sectors, and ATC Microphone Check (AMC) for instructing a stuck-transmitter aircraft to check its radio. Messages can be single-element ("CLIMB TO FL360") or multi-element, chaining several instructions into one exchange, and a free-text option covers anything the structured set does not.
As a flight crosses from one control centre to the next, CPDLC responsibility is handed over cleanly. The unit currently talking to the aircraft is the Current Data Authority (CDA); it nominates the next centre as the Next Data Authority (NDA), and the connection transfers as the flight passes the boundary — often at the same moment the voice frequency changes. This is the datalink equivalent of "contact the next controller on 123.45."
FANS 1/A and ATN B1: Two Systems, Two Protocols
Here is the part that confuses newcomers: there is not one CPDLC, there are two, and they are not interoperable. They do similar jobs with different underlying protocols.
FANS 1/A (and the enhanced FANS 1/A+) is the older, oceanic-first system. It carries CPDLC inside the ACARS protocol — the same character-oriented, telex-derived format ACARS has always used — typically over satellite (SATCOM) and HFDL, and also over VDL. Because SATCOM and HFDL reach where nothing else does, FANS 1/A became the standard for long oceanic and remote crossings, bundling clearances, pilot requests and position reporting. FANS 1/A+ adds refinements such as a message latency monitor.
ATN B1 — known in Europe as Protected-Mode CPDLC — is the newer continental system. It uses the Aeronautical Telecommunication Network (ATN/OSI) protocol rather than ACARS, and it runs over VDL Mode 2. It is the technology Europe standardised on to meet the performance its continental datalink rules demand, delivering the CM logon plus the ACM, ACL and AMC applications for busy en-route airspace.
Because one is built on ACARS and the other on ATN/OSI, an aircraft equipped for one does not automatically speak the other. Historically, US and oceanic operations leaned on FANS 1/A while European continental airspace moved to ATN B1 — which is why many modern airliners are "dual-stack," carrying both so they can operate seamlessly across regions.
|
FANS 1/A (+) |
ATN B1 |
| Underlying protocol |
ACARS (character-based) |
ATN / OSI |
| Datalinks used |
SATCOM, HFDL, VDL Mode 2 |
VDL Mode 2 |
| Primary use |
Clearances, requests, position reporting |
Clearance & communications management (ACL, ACM, AMC) |
| Typical airspace |
Oceanic and remote |
Continental en-route |
| Common region |
US domestic (Data Comm) & oceanic |
European upper airspace |
The Datalinks That Carry It
CPDLC is an application, so it always needs a link underneath it — and those links are exactly the ones covered elsewhere on this blog.
VDL Mode 2 is the VHF workhorse, running at roughly 31.5 kbps and carrying both continental ATN B1 CPDLC and FANS traffic. SATCOM — via Inmarsat or Iridium — is the oceanic backbone, keeping aircraft connected where there is no ground station for a thousand miles. HFDL fills in the polar and deep-ocean gaps that even satellites once struggled with, and it explicitly carries CPDLC alongside airline operational (AOC) and surveillance messages. A legacy low-rate VHF option (Plain Old ACARS, ~2.4 kbps) still lingers in regions without full VDL Mode 2 coverage.
The key idea: CPDLC shares these datalinks with ordinary ACARS airline messages. The same onboard Communications Management Unit that sends an ACARS position report or an engine-health message also carries the ATC clearance — it simply routes each message to the right recipient over the most efficient channel available.
CPDLC-DCL: Departure Clearance by Datalink
The form of CPDLC most travellers unknowingly benefit from is the Departure Clearance service, CPDLC-DCL. Instead of a crew requesting and copying their pre-departure clearance by voice at a congested airport, the clearance is delivered straight to the cockpit as a datalink message.
In the US, CPDLC-DCL has been deployed at more than fifty major airports as part of the FAA's Data Comm programme, using VDL Mode 2 — a link roughly twenty times faster than the legacy VHF ACARS network. The operational payoff is concrete: clearances arrive faster and error-free, crews can push back sooner, and controllers spend less time reading long clearances aloud. This is also the clearest bridge to observable data — a faster, cleaner departure clearance shows up downstream as an earlier pushback and departure time.
Where CPDLC Shows Up in a Flight Plan
CPDLC capability is declared in the ICAO flight plan. Operators insert the letter J with a number in Item 10 — J1 for ATN VDL Mode 2, and J2 through J7 for the various FANS implementations — and add COM/CPDLC in Item 18. An aircraft equipped for several systems lists several codes (for example J1J2).
Operationally, you meet CPDLC in three broad places. Over the oceans — the North Atlantic and Pacific — it runs as FANS 1/A over SATCOM and HFDL, usually paired with ADS-C (a contract-based position-reporting service; note this is distinct from the ADS-B broadcast that powers live tracking). In European continental upper airspace it runs as ATN B1 over VDL Mode 2 under Europe's datalink mandate. And in the US it appears both as en-route Data Comm and as the airport CPDLC-DCL service described above.
What You Can Actually Access — and Where AirLabs Fits
Here is the honest boundary, and it is the same one we draw for other operational data. CPDLC messages are a private channel between a specific aircraft and a specific control centre. They are not published in commercial flight data feeds — no flight API exposes the live CPDLC message stream, because it is operational air-traffic-control communication, not surveillance. If you ever see a product implying otherwise, be sceptical.
What is available — and what the AirLabs API provides — is the operational result of all this coordination:
- The Real-Time Flights API (
/flights) gives you the position, altitude, heading and speed of airborne aircraft. You see the reroute or the oceanic track a CPDLC clearance produced — the lat, lng, alt, dir and status — not the clearance text behind it.
- The Flight Information API (
/flight) returns a flight's status, scheduled and actual times, gate and terminal — the visible outcome of a datalink departure clearance and everything that follows it.
- The Schedules API (
/schedules) returns departure and arrival boards, where faster CPDLC-DCL clearances influence pushback timing.
- The Flight Delays API (
/delays) surfaces the delays that datalink efficiency is meant to reduce.
- The Fleets database (
/fleets) resolves the aircraft type. Datalink equipage broadly tracks aircraft generation and type, though — to be precise — the API reports the aircraft, not its per-flight CPDLC capability.
- The Flight Alert API (
/alert) pushes status changes to you as webhooks, so you can react to movement events without polling.
In short: CPDLC is the private communications layer, and AirLabs is the observable operational-data layer that sits on top of it. Understanding CPDLC helps you interpret why a flight rerouted or departed exactly when it did — but the data you build products on is the position, status and timing it ultimately produces.
Why This Matters for Developers
You do not need CPDLC access to build an excellent aviation product — you need the movement data it helps generate, and that is exactly what a flight data API delivers. A live tracker, an airline operations dashboard, a "where is my flight" feature, a delay-monitoring tool: all of them consume the observable layer. Knowing how the datalink beneath it works simply makes you a better reader of that data — you understand what an oceanic track change or an unusually quick pushback actually reflects.
Supported API Features
Our Developer API allows you to create a custom experience for your users and increase the value of your product:
- Real-Time Flights API (
/flights) for live aircraft positions, altitude, heading and speed — filterable by bounding box, airline, registration and route.
- Flight Information API (
/flight) for the full status of a flight by number, including actual times, gate, terminal, delay and aircraft type — inline in one response.
- Schedules API (
/schedules) for airport departures and arrivals boards.
- Flight Delays API (
/delays) for monitoring and highlighting delayed flights.
- Flight Alert API (
/alert) to subscribe to status changes and receive push notifications without polling.
- Airports, Airlines and Fleets databases to resolve codes into full names, aircraft types and details.
- Field selection via
_fields to keep responses fast, plus JSON, XML and CSV formats.
- An open-source MCP server to query all of this from an AI agent.
- A single API key across every endpoint — no multi-provider integration.
You can try it right now without any obligation! Get a free flight API plan and see for yourself that we have exactly the data you need!
If you need more information, don't hesitate to contact us. We are always happy to chat with our customers and are sure to find a customized solution for each request.
