ACARS explained for developers. What the Aircraft Communications Addressing and Reporting System is, how it works, OOOI events, message types, and how the operational data ACARS produces — actual times, positions, status — reaches your app through a flight data API.
If you have worked with our articles on ADS-B, HFDL and VDL, you have already met the family of datalink technologies that let aircraft talk to the ground without a human reading numbers over a radio. ACARS is the oldest and most foundational member of that family, and it is the one whose output you are most likely to consume in a travel or logistics application — often without realizing it.
ACARS stands for Aircraft Communications Addressing and Reporting System. It is a digital datalink system, designed by ARINC and deployed in 1978, for transmitting short text messages between an aircraft and ground stations over VHF/HF radio or satellite. Before ACARS, every coordination message — gate changes, fuel figures, delay reasons, position reports — was relayed by voice between the flight crew and ground personnel. ACARS automated that exchange, turning routine operational communication into structured, machine-readable messages.
For a developer, the important thing is not the radio physics but the data. ACARS is one of the primary mechanisms by which the real, operational truth of a flight — when it actually pushed back, when it actually got airborne, where it is, why it is late — gets off the aircraft and into the systems that airlines, airports and data providers run. When your app shows an "actual departure time" or a live "en-route" status, there is a good chance an ACARS message sits somewhere upstream of that value.
This guide explains what ACARS is, how it works, what kinds of messages it carries, and — most usefully for builders — how the operational data that ACARS generates reaches your application through the AirLabs API, without you needing a radio receiver or a datalink subscription.
"ACARS is text messaging for aircraft. You will almost never touch the raw messages — but the timestamps, positions and statuses they produce are exactly the fields your users care about. The job of a flight data API is to turn that messy signal into clean JSON."
ACARS follows a point-to-point model inherited from the telex networks it was originally built on. An aircraft's onboard unit composes a short message and transmits it; a ground network routes it to the right recipient; replies come back the same way.
On the aircraft, the equipment responsible is the Management Unit (MU) or, in newer aircraft, the Communications Management Unit (CMU). It acts as a router for data sent and received, and it can automatically pick the most efficient available channel. Messages travel by one of three link methods: VHF or VDL (VHF Data Link, line-of-sight), HF or HFDL (HF Data Link, added largely for polar routes), or SATCOM (satellite, important where there is no ground coverage, such as over oceans).
On the ground, a Datalink Service Provider (DSP) — historically ARINC or SITA — moves messages between the radio network and the airline's or agency's systems. Because the network is modeled on point-to-point telex, all messages pass through a central routing point, where they can be pre-configured to reach the correct destination automatically: clearances to air traffic control, gate assignments to airport operations, maintenance alerts to engineering.
The practical upshot is that ACARS is not one feed but a routing system carrying many different message types between many parties. What a data provider ultimately surfaces to you is the operationally meaningful subset: the events and reports that describe what a flight is doing.
The single most important concept to understand about ACARS — and the one most directly relevant to anything you build — is the OOOI event.
OOOI stands for the four milestones of a flight's ground-and-air cycle:
| Event | Meaning | Triggered by |
| Out | Aircraft pushes back from the gate | Parking brake released / doors closed |
| Off | Aircraft becomes airborne | Weight-off-wheels sensor |
| On | Aircraft touches down | Weight-on-wheels sensor |
| In | Aircraft arrives at the gate | Parking brake set / doors opened |
A core function of ACARS, present since the very first 1978 deployment, is to automatically detect and report these four events using sensors on the doors, parking brake and landing gear. When the aircraft pushes back, an "Out" message is generated and timestamped without anyone lifting a finger.
These timestamps are the backbone of operational aviation data. Airlines use them for crew pay (hourly rates historically depended on whether the aircraft was airborne), for scheduling, and — crucially for your users — for on-time performance. The "actual departure time" and "actual arrival time" that drive delay calculations, passenger notifications and connection-risk logic are, at their origin, OOOI events. When you compare a scheduled time to an actual time to compute a delay, you are comparing a published schedule against an ACARS-derived "Out" or "In" timestamp.
This is why OOOI matters to developers even if you never see an ACARS message: the out/off/on/in truth is what separates a real flight-status product from one that just echoes the published timetable.
Beyond OOOI events, ACARS carries a wide range of content. Industry standards group it into three broad categories, and knowing them helps you understand where flight data comes from.
Air Traffic Control (ATC) messages are used to request and deliver clearances — pre-departure clearances, datalink ATIS, oceanic clearances. ACARS fills a niche role here; the more modern, dedicated system for controller-pilot datalink is CPDLC, but ACARS still carries meaningful ATC traffic.
Aeronautical Operational Control (AOC) and Airline Administrative Control (AAC) messages are the communications between an aircraft and its airline base. This is the richest category for operational data: load and trim sheets, fuel figures, OOOI events, delay codes, gate and connection information, weather reports, and automatically triggered maintenance data such as engine performance and fault codes. Most of what makes a flight "knowable" operationally rides in this category.
The content can be highly varied — anything from a routine position report to an automatically generated alert that a system has exceeded a tolerance. For a data consumer, the value is that these messages are structured and automatic: they are generated by the aircraft's systems on defined triggers, which is exactly what makes them aggregatable into a reliable dataset.
Developers often conflate ACARS with ADS-B, because both are ways aircraft data reaches the ground. They are different systems that complement each other, and understanding the distinction clarifies what each contributes.
ADS-B broadcasts an aircraft's GPS-derived position, altitude, speed and identity continuously on 1090 MHz, primarily for surveillance — knowing where every aircraft is, right now. ACARS operates on entirely different frequencies (around 129–131 MHz for VHF) and carries operational text — OOOI events, fuel, maintenance, gate info — rather than a continuous position stream.
A useful way to see it: ADS-B answers "where is this aircraft?"; ACARS answers "what is this flight doing operationally?". ADS-B gives you the track; ACARS gives you the milestones and the operational context around it. The two are frequently fused — an ACARS message carries the flight number and registration, while ADS-B carries the ICAO 24-bit hex address, so joining them through an aircraft database produces a far richer record than either alone.
That fusion is precisely the kind of work a data provider does for you. Rather than running one receiver for 1090 MHz and another for 129 MHz and writing the correlation logic yourself, you consume a single feed where positional data and operational status already sit together in one object.
Here is the part that matters most for builders, and the honest framing of it: AirLabs does not hand you raw ACARS messages. Raw ACARS is a specialized datalink stream that hobbyists capture with software-defined radios and that airlines receive through DSP contracts. What AirLabs does is deliver the operational result of that data — the actual times, statuses and positions — cleaned, correlated and exposed through a standard REST API.
In other words, ACARS (alongside ADS-B and other sources) is part of what feeds the dataset; the AirLabs endpoints are how you read the outcome. The OOOI truth surfaces as concrete fields you already use.
The Flight Information API is the clearest example. A single flight object carries the operational milestones an OOOI sequence ultimately produces:
GET https://airlabs.co/api/v9/flight?flight_iata=4Z21&api_key={KEY}
{
"flight_iata": "4Z21",
"dep_iata": "JNB",
"dep_time": "2021-07-21 18:50",
"dep_actual": "2021-07-21 19:02",
"arr_iata": "CPT",
"arr_estimated": "2021-07-21 21:04",
"status": "en-route",
"lat": 33.45501689,
"lng": -118.7383119,
"alt": 10668,
"speed": 942,
"squawk": "3726",
"reg_number": "ZS-SNH",
"hex": "00B1C4",
"updated": 1626858778
}In this one response, dep_actual is the real pushback/airborne reality that an OOOI "Out"/"Off" sequence underlies; status ("en-route") reflects that the flight is airborne; and the lat/lng/alt/speed give the position. The hex (ICAO 24-bit address) and reg_number are the identifiers that let ACARS-style operational data and ADS-B-style positional data be joined into one record — exactly the fusion described above, already done for you.
Because ACARS-derived operational data is woven through several endpoints, it helps to know which tool surfaces which slice.
The Airport Schedules API is where OOOI events become a departures/arrivals board: each row carries scheduled, estimated and actual times plus a live status, so you can see which flights have actually gone "Out" and "Off" versus which are still scheduled. This is the natural home for on-time-performance logic built on actual-versus-scheduled comparison.
The Real-Time Flights API surfaces the positional side — live lat, lng, alt, dir, speed, squawk and hex for airborne aircraft. This is the ADS-B-style track that you fuse with operational status.
The Fleets Database ties an aircraft's identifiers together — reg_number, hex, model, operator — which is the join key that makes correlating operational and positional data possible, and includes a last_seen signal time for when an aircraft was most recently heard from.
The Flight Delays API expresses the consequence of all this: when an actual time (OOOI-derived) diverges from a scheduled time, the gap is a delay, and this endpoint surfaces it directly.
Across all of them, the common thread is that you read clean JSON fields — dep_actual, status, lat, squawk, delayed — rather than decoding datalink frames. The messy origin (radios, DSPs, message formats) is abstracted away.
Understanding ACARS changes how you think about flight data quality, even though you consume it indirectly.
It explains why actual times are trustworthy: a dep_actual is not a guess, it traces back to sensor-triggered OOOI events, which is why it can differ from both the schedule and the estimate. It explains why status fields are meaningful: an "en-route" status reflects an "Off" event, not an assumption. And it explains why fusing identifiers matters: the hex and reg_number in an AirLabs response are what let operational and positional data describe the same aircraft coherently.
For a passenger app, this is the difference between "your flight is scheduled for 18:50" and "your flight actually pushed back at 19:02 and is now airborne." For a logistics or transfer service, it is the difference between planning around a timetable and planning around reality. For analytics, OOOI-derived actual times are the raw material of every on-time-performance metric worth computing.
If you are building anything that depends on what a flight is actually doing — status apps, delay and transfer logic, on-time-performance analytics, live maps — the operational data that ACARS produces is the signal you need, and AirLabs delivers it as clean JSON without any radio hardware or datalink subscription.
Our Developer API surfaces ACARS-adjacent operational data through standard endpoints:
dep_actual / arr_actual, live status, and position fields — the OOOI-derived truth of a single flight.status for departures and arrivals boards.lat, lng, alt, dir, speed, squawk and hex for airborne aircraft.reg_number, hex and aircraft details, with a last_seen signal time.hex and reg_number identifiers throughout, so operational and positional data correlate to one aircraft._fields selection to keep responses compact.You can try it right now without any obligation. Get a free flight API plan and see for yourself that we have exactly the operational data your product needs.
If you need more information, don't hesitate to contact us. We are always happy to help you find the right approach for your use case.
Explore AirLabs, or create an account instantly and start using API.
Get FREE API Key