File-based Intake
Not every airline system exposes an API. Many departure control systems integrate only through their own vendor, and many operations teams already work from manifest exports. Nexa treats files as a first-class integration channel, with the same canonical model, validation, PII discipline, and audit as an API connector — not as a workaround.
How it works
- The file arrives — uploaded by an operator in the console, or delivered on a scheduled drop agreed during onboarding.
- Its format is detected from its content, never from its name or declared type, so a CSV named
.xlsor a spreadsheet exported by a legacy tool is still read correctly — and a malicious file cannot choose its own parser. - A mapping profile translates the layout onto the canonical fields.
- The operator sees a preview — flights, PNRs, passengers, and every diagnostic (missing contact, unknown cabin code, a date with no time) — before anything is committed.
- Commit creates the manifest of record for that flight, and the disruption proceeds exactly as it would from an API.
Mapping profiles
Each export layout gets a mapping profile: a declarative, versioned description of where each canonical field lives in that file — which sheet, which column band, which vocabulary dictionary, which date format.
- Authored once per layout, not per file. When a new layout arrives, Nexa's trained models draft the profile from a sample; a person reviews it; once approved it is frozen and reused for every future file with that layout.
- Executable without a model. Once approved, a profile runs deterministically. No AI sits in the data path of a live disruption.
- Closed by construction. A profile can only reference canonical fields, reviewed dictionaries, and a fixed menu of formats and validators. It cannot contain code.
- Handles real exports. Repeated column labels, multi-row headers, multiple sheets (including a separate sheet of PNRs in error), multi-leg itineraries, and the airline-assigned new flight when the export carries it.
- Explicit on invalid data. Each field declares what happens when a value fails validation — warn and blank it, reject the file, or keep it — so nothing is dropped silently.
Built-in cross-file checks include: at least one contact per PNR, cabin-mix sanity, departure within the expected window, maximum flights and passengers per file, and presence of the disrupted segment.
File wins, per flight
When a manifest of record exists for a flight, it is the manifest for that flight: the file is what your operations desk sent for this event, and a system that disagrees is the one that is out of date. This rule is applied per flight, never per airline — every other flight keeps reading your PSS, in the same request, with no mode to switch.
Because a file overrides live data, it is never silent: every surface shows the manifest's source, the file name, who uploaded it and when, and its freshness.
Security and PII
Workbooks are inspected before they are parsed: files containing macros or external links are rejected, and archives whose decompression ratio indicates a decompression bomb are refused.
Files are subject to the same boundary as API connectors: document numbers and dates of birth are tokenized on commit, and the raw file is retained only in isolated storage under your retention policy.
Supported formats
| Format | Notes |
|---|---|
Excel workbooks (.xlsx) | Multi-sheet; streamed, so large manifests do not need to fit in memory. |
Delimited text (.csv, .tsv) | Delimiter detected from content. |
| Type-B PNL / ADL | Through a dedicated connector, agreed during onboarding. |
When to use it
- The DCS or PSS has no API, or integrates only through its vendor.
- Go-live must not wait for an API connector to certify — files carry the first live disruptions while the API connector is completed.
- A fallback channel for when an upstream system is down.
Where to next
- Data requirements — what a manifest should contain.
- How Nexa builds your connectors
- Airline systems (PSS / DCS)