US Airline Traffic by Carrier — Monthly, Per Record

Turn the U.S. DOT T-100 carrier summary into clean, per-record traffic-performance benchmarks — one row per airline per month, with departures, passengers, seats, load factor and domestic/international splits, ready to benchmark U.S. air-carrier operations month by month.

Each source row becomes one clean, flat record with numeric fields coerced to real numbers, a stable source-native record_id, and provenance stamped on every row: source, resource id, the public-domain licence notice, the required attribution, a UTC retrieval timestamp and an interpretation caveat.

What one record represents

The source is the U.S. Department of Transportation dataset q4tb-tbff — AFF - T100 Segment Summary By Carrier, published on the DOT open-data portal. Each record is one air carrier for one reporting month: total performed departures, enplaned passengers, available seats and load factor, plus per-flight and distance metrics and domestic / outbound-international / inbound-international splits. The carrier field is named explicitly in the query because the source's default view hides it — so unlike the raw portal view, this Actor delivers the airline on every row.

For each record you get a composite record_id built from the source-native key, the analytic columns listed below (reproduced verbatim, numbers as numbers), and the provenance block. Columns include carrier (the airline), reporting_month, total_departures, total_passengers, total_seats, total_load_factor, the per-flight metrics, and the domestic_*, outbound_international_* and inbound_international_* summaries.

Coverage and volume

The live table holds 39,603 carrier-month records — the grain is month × carrier across roughly 148 reporting months and hundreds of carriers — that is the record capacity of a full pull.

The Actor pages through the source with keyless SODA queries ($limit/$offset) ordered by the source-native key for a stable total order, and stops as soon as your Maximum records cap is met. Crucially, the source's default resource view hides the carrier column; this Actor issues a full SoQL $query that names carrier explicitly and orders by carrier and month, so every delivered record carries its airline (the raw default view does not).

Licence and attribution

This is a public-domain U.S. Government work (17 U.S.C. §105) — free to use, redistribute and build on. The full notice travels on every record in the licence field:

U.S. DOT / Bureau of Transportation Statistics. Public-domain U.S. Government work (17 U.S.C. 105). Reproduced verbatim; no third-party content or logos.

The required attribution — U.S. DOT / Bureau of Transportation Statistics — is present on every record. No third-party content or logos are included.

Interpretation caveat

Operational totals are monthly per-carrier T-100 summaries. Load factor is a percentage; payload, freight and mail are in pounds; distances are in statute miles. The carrier is an airline organisation, not a person.

Values are reproduced verbatim: the Actor never rescales, re-derives or editorialises a number. Read each figure together with its column definition.

Person-data policy

The carrier field names an airline (an organisation), not a person. No natural-person columns exist in the source projection this Actor selects. There are no name, email, phone, personal-address or personal-identifier fields in the record. This is a market- and operations-level records product about air transport, not about individuals.

Data quality and freshness

Numeric fields are coerced from the source's string encoding into real numbers (integers where the value is whole, floats otherwise), and genuinely missing cells are delivered as null rather than as zero or an empty string — so you can tell "reported as zero" apart from "not reported". Text fields are passed through verbatim. Because every run re-reads the live source, the data is as fresh as the DOT portal itself: re-run the Actor whenever you want the latest published period, and the observed_at timestamp on each record tells you exactly when that row was retrieved. Delivery order is fixed by the source-native key, so a capped sample and a later full pull agree on their overlapping rows, and a run you repeat returns rows in the same order. The RUN_RECEIPT record written to the run's key-value store reports how many source rows were scanned and how many records were delivered and charged, giving you a per-run reconciliation between the door and your dataset.

Fields in detail

The record leads with record_id — a stable composite key drawn from the source's own primary key or grain — followed by the analytic columns described above and closed by a provenance block: source, source_dataset (the Socrata resource id), licence, attribution, caveat and observed_at. Every one of those provenance fields is present on every record, so a single row is self-describing: you can hand it to a colleague or a downstream system and it carries its own origin, licence and retrieval time without reference back to this page.

Provenance, licensing and compliance

Every run begins with a live source-preflight: the Actor reads the exact host's robots.txt at runtime and refuses to proceed if the crawl policy disallows the data path. The gate result — the URL read, the HTTP status, the byte length and a SHA-256 of the policy document — is written to the run's RUN_RECEIPT key-value record, so each run carries its own audit trail. The Actor identifies itself with a transparent, non-impersonating User-Agent and never attempts to bypass a block, solve a challenge, or fetch through a cache or mirror. When the door is genuinely unavailable the run fails loudly and bills nothing rather than delivering a partial or stale set silently.

Records carry no natural-person or contact fields. The output schema is a fixed structural allow-list of statistical, geographic and organisational columns; there are no name, email, phone, address, or identifier-of-a-person fields anywhere in the record, and a per-record assertion enforces that allow-list at write time. This is a records product about places, industries, markets and organisations — never about people.

Inputs

• Maximum records (maxRecords) — hard cap on records delivered and billed. Raise it to pull the full set; lower it to sample cheaply. Records are delivered in a stable, source-native order so a capped run always returns the same leading slice.

Output

Records land in the Actor's default dataset and export as JSON, CSV, Excel or via the Apify API. A tabular overview view surfaces the most useful columns for quick inspection while the full record retains every selected field and provenance stamp.

Sibling Actors

This Actor is one cell of a broader per-record data fleet. The live fleet already includes airport-facility-records, which is a directory of airport facilities — a different job and a different grain from this Actor. That Actor answers what and where an airport facility is; this Actor answers how much each airline flew and carried each month. The two are complementary, not overlapping: use the facility directory to describe airports, and this Actor to measure carrier-level traffic and operational performance. This Actor also shares its engineering — the runtime robots gate, push-then-charge billing and verbatim-value discipline — with the fleet's other public-data records Actors.

Pricing

This Actor uses Apify's pay-per-event model. You are charged a flat $0.05 per record actually delivered to the dataset — nothing else. There is no monthly rental, no per-run base fee, and no charge for compute time. If a run delivers 40 records you pay $2.00; if it delivers 10,000 you pay $500.00. The billing is wired after delivery: each record is pushed to the dataset first and only then does the matching per-record event fire, so a mid-run failure can only ever under-charge you, never over-charge. Set Maximum records to cap spend precisely — you will never be billed for more than you asked for, and you will never be billed for records that were not delivered.

Typical uses

Benchmark airline operations month by month; track departures, passengers, seats and load factor by carrier; separate domestic from international activity; monitor a competitor's capacity; or feed an aviation-market, competitive-intelligence or investor model with clean carrier-month records.

What this Actor does not do

It does not forecast or model, does not merge multiple DOT tables into one record, and does not include the redundant geocode/address columns some source views expose. It gives you faithful, public-domain, analysis-ready records — one row per source row — with a provenance trail you can audit on every run.