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.

Connectors are built on one model for every system — Amadeus Altéa, Sabre, Navitaire, and custom or regional PSS / DCS platforms: a single tenant-scoped adapter behind a stable interface, with two directions of traffic. Nexa builds and operates the connector; the airline shares documentation and access. See How Nexa builds your connectors. Vendor channels are enabled per commercial agreement with each airline.

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.

The exact fields exchanged in each direction are listed in Data requirements.

Channels, including systems without an API

Channel	Typical use
Pull — Nexa calls the PSS / DCS API	Manifest and PNR retrieval at case-open and on refresh.
Push — the airline's systems call the Partner API	Disruption events, manifest updates, re-accommodation decisions.
Stream — Nexa subscribes to an event stream	Airlines with an existing integration bus.
File — manifest exports	DCS platforms that integrate only through their vendor or through exports. See File-based intake.

A DCS that does not offer an API is not a blocker: the manifest arrives as an export through the file channel — with the same canonical model, validation, and audit — while any vendor-side integration is agreed in parallel. Channels combine: a common setup is PSS pull for PNRs, operations-system push for flight events, and DCS files for the manifest.

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 → Altéa web services under the airline's own Amadeus contract — see Amadeus Altéa connector
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 or regional PSS / DCS	Airline-side webhook → Nexa Partner API, or file exports	Per-tenant adapter built by Nexa from the system's documentation

The customer-facing API is the same for all of them — 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 /partner/v1/disruptions
Authorization: Bearer <partner-api-token>

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.

The event carries an externalEventId, which makes the call idempotent. Nexa replies with the case URN — see the Partner API for the full request and response. 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 and DCS platforms and share their documentation.
• Agree the channel per system (pull, push, stream, or file) and sign off the field mapping against Data requirements.
• If push is in scope: airline registers Nexa's POST /partner/v1/disruptions endpoint as a disruption webhook target.
• 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 3–6 weeks for a system with a documented API, and days for push-only or file-based intake — which can carry the first live disruptions while the API connector is certified.

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

• Data requirements — the canonical fields, per source system.
• Amadeus Altéa connector — interfaces and transaction volumes for Altéa-hosted airlines.
• Working with your disruption products — re-protection, compensation, and notification tooling you already run.
• File-based intake — for systems without an API.
• Operations & scheduling systems — flight events from your OCC tooling.
• 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.