Data Requirements
This page is the data contract between your airline systems and Nexa: which fields Nexa needs, which system usually holds them, whether they are required, and what Nexa does with each one. It is written for the IT team that will scope the integration.
Whatever system a field comes from — PSS, DCS, an operations suite, or a file export — the connector translates it into Nexa's canonical data model. The tables below describe that canonical model. Field names are the canonical ones; your systems do not need to use them.
To run a live disruption end to end, Nexa needs only two things:
- A disruption event — which flight, and what happened to it.
- A manifest — for each booking: the PNR locator, cabin, passenger names and types, and at least one contact channel.
Every other field on this page enriches the outcome (better hotel matching, special-needs handling, connection protection, card issuance) but is not a prerequisite for go-live.
Which system usually supplies what
| Data | PSS | DCS | Ops / scheduling | Nexa flight data |
|---|---|---|---|---|
| Flight status, cancellations, diversions, delays | ● primary | ● independent confirmation + prediction | ||
| Disruption reason, aircraft | ● | ○ | ||
| Passenger manifest for a flight | ● | ● | ||
| PNR, contacts, itinerary, loyalty tier | ● | ○ | ||
| SSR / special-service codes | ● | ● | ||
| Check-in status, seat, boarded / no-show | ● | |||
| Re-accommodation (the passenger's new flight) | ● | ● | ○ | |
| Write-back: remark on the PNR | ● |
● typical source · ○ sometimes available
Nexa always runs its own flight-data platform in parallel. Your operations system is an additional, authoritative source — see Operations & scheduling systems for how the two are reconciled.
1. Disruption event (per flight)
One event per thing that happens to a flight. Updates to the same flight (delay grows, delay becomes a cancellation, a cancellation is reverted) are sent as further events for the same flight.
| Field | Required | Description | Used for |
|---|---|---|---|
airline | ✔ | Operating carrier, IATA code. | Tenant routing. |
flight_number | ✔ | Flight number. | Flight identity. |
scheduled_departure_utc | ✔ | Scheduled departure, ISO-8601 UTC (the date identifies the flight instance). | Flight identity; stay-length computation. |
origin, destination | ✔ | IATA airport codes. | Airport of care; hotel search area. |
event_kind | ✔ | CANCELLED, DIVERTED, DELAY, or RETRACTION (a previous event is withdrawn). | Whether and how a disruption opens. |
delay_minutes | for DELAY | Current expected delay. | Compared against your delay thresholds. |
diverted_to | for DIVERTED | IATA code of the diversion airport. | Becomes the airport of care. |
observed_at | ✔ | When your system recorded the event. | Ordering; stale-event rejection. |
external_event_id | ✔ (push) | Your unique ID for the event. | Idempotency — replays never duplicate. |
reason | optional | Weather, technical, ATC, crew, operational, … | Entitlements (e.g. EU261 extraordinary circumstances); scope of the disruption. |
estimated_departure_utc, actual_departure_utc, actual_arrival_utc | optional | Operational times. | Flight phase (pre-departure / in-flight / landed). |
aircraft_type | optional | Equipment. | Context for operators. |
Which events open a disruption is your policy, configured per airline: cancellations and diversions always open one by default; delays open one only above thresholds you set, optionally different per flight phase and per airport.
2. Manifest — booking (PNR) level
| Field | Required | Description | Used for |
|---|---|---|---|
pnr_locator | ✔ | Booking reference. | Groups travelling together are kept together. |
cabin_class | ✔ | ECONOMY, PREMIUM, BUSINESS (your booking classes are mapped by dictionary). | Hotel category and entitlements per your policy. |
contact.email / contact.phone | at least one | Contact channels as held in your PSS. | Passenger notifications and self-service offers. |
contact.language | optional | ISO 639-1. Defaults to English. | Language of every message and of the passenger app. |
segments[] | recommended | The full sold itinerary, in order (see §4). | Protecting the passenger to their final destination, not just the disrupted leg. |
final_destination | optional | IATA code of the journey's end. Derived from segments when present. | Connection-aware rebooking. |
reaccommodated_segment | recommended | The new flight your airline assigned after the disruption (see §4). | Number of hotel nights; passenger itinerary in the app. |
3. Manifest — passenger level
| Field | Required | Description | Used for |
|---|---|---|---|
first_name, last_name | ✔ | As on the booking. | Hotel rooming list, vouchers, messages. |
pax_type | ✔ | ADT, CHD, INF. | Room occupancy; minors are never separated from their group. |
external_pax_key | recommended | Your stable passenger identifier within the PNR. | Idempotent updates when the manifest is re-sent. |
loyalty_tier | optional | Your tier names, mapped to BASE … DIAMOND by dictionary. | Prioritization and entitlements per your policy. |
ssr_codes[] | optional | IATA SSR codes as carried on the PNR (WCHR, WCHC, BLND, DEAF, MAAS, UMNR, PETC, meal codes, …). | Accessible rooms, meet-and-assist, unaccompanied minors, pets; SSR preservation when rebooking. |
nationality | optional | ISO 3166 country. | Transit-visa feasibility when proposing alternative routings. |
date_of_birth | optional | Tokenized on arrival — see below. | Derives senior / minor status. |
document_type, document_number | optional | Tokenized on arrival. | Hotel check-in where the property requires it. |
operation_country | optional | Country of residence / operation. | Issuing prepaid compensation cards. |
gender | optional | As on the booking. | Rooming rules where your policy uses them. |
4. Itinerary segments
Used both for the sold itinerary (segments[]) and for the new flight your airline assigned (reaccommodated_segment). The two are deliberately kept separate: the flight they were booked on and the flight they were moved to are different facts.
| Field | Required | Description |
|---|---|---|
flight_number, carrier | ✔ | Flight and operating carrier (differs from marketing carrier on interline legs). |
origin, destination | ✔ | IATA codes. |
departure (date + time) | ✔ | Scheduled departure. When only a date is known, Nexa assumes the start of the local day and says so to the operator rather than guessing silently. |
arrival (date + time) | optional | Scheduled arrival. |
segment_order | for segments[] | 1-based position in the journey. |
seat, check_in_status | optional (DCS) | Seat and check-in state for the leg. |
is_interline | optional | Leg flown by a partner carrier. |
5. Operational state during recovery (DCS)
Optional, but valuable during a long disruption:
| Field | Description | Used for |
|---|---|---|
boarded / no_show | Per passenger, per flight. | Closing out passengers who flew; releasing unused rooms and transport. |
voucher_accepted | Passenger took an airline-issued alternative at the counter. | Avoiding double care. |
6. What Nexa writes back
| Target | Content | When |
|---|---|---|
| PNR remark (OSI / free text) | A short service record: hotel, nights, transport, card issued, with Nexa's reference. | After each confirmed service, when write-back is enabled. |
| Webhook-out to your systems | Case, booking, and passenger events. | See Webhooks. |
Nexa never issues tickets, changes inventory, or modifies the itinerary in your PSS. Re-accommodation decisions remain yours.
Data handling
- Sensitive identity data is tokenized at the adapter boundary. Dates of birth, document numbers, and similar fields are exchanged for a token before they reach the platform core. Plaintext never enters case storage, logs, or analytics.
- Your PSS stays the system of record. Nexa keeps references to PNRs and passengers, plus what is needed to operate the disruption, under the retention you configure.
- Every record carries its freshness. Data older than the agreed maximum staleness is served with a stale flag, never silently.
- You are the data controller; Nexa is the processor. See Compliance.
Formats
The canonical model is the target, not a format you must adopt. Nexa's connectors read:
- JSON over REST (pull or push), and event streams.
- Spreadsheet and delimited exports (
.xlsx,.csv,.tsv) — see File-based intake. - Industry passenger-list messages (Type-B PNL / ADL) through a dedicated connector.