Airline Systems (PSS / DCS)

Nexa is not a replacement for the airline's own systems — it is the orchestration layer that sits next to them. Every tenant already runs a Passenger Service System (PSS) and a Departure Control System (DCS) for flights, manifests, ticketing, and re-accommodation. Nexa adapts to whichever ones the airline runs and never asks the airline to migrate.

The supported shapes today are Amadeus Altéa, Sabre PSS, Navitaire, and custom in-house systems. The integration model is the same in all four cases: a single tenant-scoped adapter behind a stable interface, with two directions of traffic.

Why this is a first-class integration

The airline's PSS is the system of record for the parts of a disruption Nexa does not own:

• The flight itself, the schedule, and the cancellation / delay / reroute decision.
• The passenger manifest and the PNR — Nexa never stores PNRs or travel documents.
• The re-accommodation decision (which next flight each PNR is moved to).

Nexa owns the parts the airline needs help with under disruption: hotel allocation, payment, transport, communications, and operator workflow. The two halves cooperate through the airline adapter.

What Nexa uses the airline systems for

Direction	Capability	Triggered by
Inbound (push)	Receive a confirmed disruption event for a flight	Airline DCS, on cancellation / delay / reroute
Inbound (push)	Receive the re-accommodation decision per PNR	Airline operations, once next flights are assigned
Inbound (push)	Receive operational state updates (boarded, no-show, accepted-voucher)	Airline DCS during the recovery window
Outbound (pull)	Fetch the passenger manifest for a disrupted flight	Nexa, at case-open and on operator refresh
Outbound (pull)	Resolve PNR-level details (group size, SSR flags, tier)	Nexa, when sub-cases are provisioned

The push channel is what most airlines integrate first. The pull channel is optional and switches on once the tenant grants Nexa programmatic PSS access — many tenants run with push-only and supply manifest data inline with the disruption event.

Architecture

The Airline adapter is a tenant-scoped, zero-persistence component. It owns the shape of every PSS system Nexa supports and translates partner-specific payloads into the canonical Nexa data model — same field names, same enums, same units regardless of whether the underlying PSS is Altéa, Sabre, or a custom feed.

PSS systems supported

PSS / DCS	Inbound shape	Outbound shape
Amadeus Altéa	Airline-side webhook → Nexa Partner API	Nexa adapter → Amadeus PSS APIs (tenant-managed credentials)
Sabre PSS	Airline-side webhook → Nexa Partner API	Nexa adapter → Sabre PSS APIs (tenant-managed credentials)
Navitaire	Airline-side webhook → Nexa Partner API	Nexa adapter → Navitaire APIs (tenant-managed credentials)
Custom in-house	Airline-side webhook → Nexa Partner API	Per-tenant adapter shape co-designed during onboarding

The customer-facing API is the same for all four — the airline's DCS calls Nexa's Partner API webhook, and Nexa's adapter handles whatever sits behind it.

Amadeus appears in two independent integrations in this platform: as the PSS described on this page, and as a hotel vendor through Amadeus Self-Service (Amadeus integration page). The two roles use different APIs, different credentials, and different adapters. A tenant may use one, both, or neither.

Inbound: disruption events

The airline's DCS pushes disruption events to Nexa via the Partner API:

POST /v1/cases
Authorization: Bearer <partner-api-token>
Idempotency-Key: <externalEventId>

The body is the canonical disruption shape — flight identifier, reason, expected impact window, and either a manifest excerpt or a reference for Nexa to pull. The same endpoint is used for the initial event and for follow-up updates (re-accommodation decisions, state transitions); each update carries an event ID and is processed idempotently.

Nexa replies with the case URN. From that point, the operator console and the passenger PWA reflect the disruption in seconds.

Outbound: manifest and PNR resolution

When the airline grants Nexa programmatic PSS access, the airline adapter fetches what it needs at case-open:

1. The disruption event arrives.
2. Nexa creates the case, then asks the adapter for the canonical manifest.
3. The adapter calls the airline's PSS using tenant-managed credentials, translates the response into Nexa's canonical manifest shape, and returns it.
4. Sub-cases are provisioned from the canonical manifest — one per PNR, families grouped.

The adapter is zero-persistence. Manifest payloads are translated and consumed in-memory; PNRs and passenger documents are never stored at rest. What Nexa retains is the URN reference back to the PSS record — see Data model for the URN scheme.

Authentication

Direction	Auth
Airline DCS → Nexa (inbound)	Partner-API M2M token (OAuth2 client credentials, INTEGRATION scope)
Nexa → airline PSS (outbound)	Tenant-managed credentials, stored in the tenant secrets namespace

The inbound token is provisioned during onboarding and rotated on the tenant's schedule. Outbound credentials are whatever the airline's PSS contract issues — Nexa stores them per-tenant and never shares them across airlines.

Rate limiting

Inbound traffic is rate-limited per tenant at the Partner API layer. Outbound traffic to the airline's PSS goes through the same cluster-wide egress shaping every other partner uses (rate-limiting model in the integrations overview). PSS systems publish much lower TPS budgets than hotel inventory APIs, so the egress limiter is what keeps Nexa from saturating an airline's PSS during a wide-area disruption.

Idempotency

Two layers of idempotency apply:

• Event ingestion — every inbound event carries an externalEventId. Replays of the same event ID return the same case URN; they never create a duplicate case. See Idempotency.
• Manifest fetch — the same flight URN always resolves to the same canonical manifest URN. Operator-driven refreshes re-pull from the PSS but do not duplicate sub-cases.

Mock mode

Every airline adapter ships with a sibling mock. In sandbox environments the mock returns deterministic disruptions and manifests, so tenants can validate end-to-end flows — case creation, sub-case provisioning, allocation, booking, notification — without ever touching the live PSS.

The flag is per-tenant. Customer Success flips it from mock to live once production credentials are validated.

Onboarding checklist

For a new tenant integrating their PSS / DCS:

• Identify the PSS shape (Altéa, Sabre, Navitaire, or custom).
• Airline registers Nexa's POST /v1/cases endpoint as a disruption webhook target in the DCS.
• Nexa issues an INTEGRATION Partner-API token to the airline's integration team.
• If pull is in scope: airline procures PSS credentials and Nexa loads them into the tenant's secrets namespace.
• The airline confirms its externalEventId format so idempotency works correctly across replays.
• First end-to-end disruption is run against a sandbox flight; the operator console shows the case live and the canonical manifest renders correctly.
• Mock-mode flag flipped to live.

Onboarding takes 2–6 weeks for a custom PSS, 1–3 weeks for a supported PSS shape, and 1–3 business days for push-only with manifest carried inline.

Compliance & data handling

The airline is the data controller for everything that flows through this integration; Nexa is the data processor. Because the airline's PSS is the airline's own system, there is no additional sub-processor to disclose for this leg of the platform.

PNRs and passenger documents (passport, national ID) stay in the airline's PSS. Nexa references them by URN. This is the same posture documented in the data model and the compliance guide.

Where to next

• Partner API — the inbound webhook contract used by the airline's DCS.
• Case lifecycle — what happens to a disruption event after it lands.
• Data model — the URN scheme and the zero-persistence rule for PNRs.
• Idempotency — replay semantics for externalEventId and other replay-safe operations.