Amadeus Altéa Connector
This page is for airlines hosted on Amadeus Altéa that need to describe the Nexa integration to Amadeus — typically through Amadeus's third-party access questionnaire. It lists the capabilities Nexa uses, the Amadeus interfaces behind them, and a transaction-volume model you can size against your own disruption history.
Nexa talks to Amadeus in two unrelated roles:
- As a hotel supplier — Nexa's own Amadeus hotel integration (Amadeus hotels), under Nexa's contract, used to search and book rooms.
- As your PSS / DCS — this page. Every flight, PNR, and passenger call is made against your Altéa, under your Amadeus contract, your office ID, and your credentials. Nexa never reads your passengers through its own Amadeus access, and the two integrations share no credentials.
Access model
- Your contract, your access point. The airline requests from Amadeus a dedicated Web Services Access Point (WSAP) and office / sign-in for Nexa under its own Altéa agreement. Nexa does not need its own airline-side Amadeus contract.
- Least privilege. Nexa reads PNRs, flight manifests, and flight status, and writes remarks. It never issues or reissues tickets, changes inventory, rebooks, or modifies itineraries.
- Credentials are stored in your tenant's isolated secrets namespace and never shared across airlines.
- Traffic is shaped platform-wide to the rate you agree with Amadeus — see Volume model.
Capabilities and the Amadeus interfaces behind them
The adapter implements Nexa's airline port — manifest for a flight, PNR, flight events, re-accommodation outcome, write remark — over Amadeus Web Services. The interfaces below are indicative: the exact messages and versions depend on the Altéa packages your airline has contracted, and are confirmed with your Amadeus account team during discovery.
| # | Nexa capability | When Nexa calls it | Amadeus interface (indicative) | Direction |
|---|---|---|---|---|
| 1 | Session management | Around every conversation | Security_Authenticate / Security_SignOut (or stateless session headers) | — |
| 2 | Passenger list for a disrupted flight | Disruption opens; operator refresh | Altéa DCS passenger list for a flight-date (DCS Customer Management) | Read |
| 3 | PNR detail: names, contacts, itinerary, SSRs, tier | Each booking is provisioned | PNR_Retrieve | Read |
| 4 | Flight status (cancel / divert / delay) | Optional — when your operations system does not push events | Air_FlightInfo or your flight-status feed | Read |
| 5 | Re-accommodation outcome (the new flight) | After your recovery tooling re-protects the PNR | PNR_Retrieve of the re-protected PNR, or Queue_List on the queue your recovery tooling places PNRs on | Read |
| 6 | Service record on the PNR (hotel, nights, transport, card) | After each confirmed service, if write-back is enabled | PNR_AddMultiElements (OSI / RM remark) | Write |
Capabilities 4 and 5 are optional: flight events can come from your operations system or from Nexa's own flight data (Operations & scheduling systems), and re-accommodation can arrive by push instead of being read back.
Volume model
Nexa calls Altéa only when a disruption happens — there is no background polling of your whole schedule or passenger base. Volume therefore scales with the number of disrupted flights and the passengers on them.
Per disrupted flight with P bookings (PNRs):
| Capability | Calls per disrupted flight | Notes |
|---|---|---|
| Passenger list (2) | 1–3 | One at open plus operator refreshes; cached and single-flighted, so concurrent screens never multiply calls. |
| PNR retrieve (3) | P | One per booking at provisioning. |
| Re-accommodation read (5) | P, or a handful of queue reads | Per booking re-read, or one queue read per cycle. |
| Remark write (6) | 1–3 × P | One per confirmed service (hotel, transport, card); zero if write-back is disabled. |
| Sessions (1) | Negligible | Sessions are pooled. |
Worked example. A wide-body cancellation with ~280 passengers in ~150 PNRs:
| Low (write-back off) | Typical | High (all services written back) | |
|---|---|---|---|
| Transactions per event | ≈ 300 | ≈ 450 | ≈ 750 |
Annual volume = disrupted flights per year × transactions per event. For example, 150 qualifying disruptions a year at the typical rate ≈ 70,000 transactions a year.
Peak rate. Transactions are spread over the recovery window (minutes to hours), not issued at once. Nexa enforces a platform-wide ceiling on transactions per second to your Altéa — set to the figure you agree with Amadeus — regardless of how many Nexa workers are running. During a region-wide event, work queues rather than exceeding the ceiling.
Coexisting with your Amadeus products
Airlines on Altéa often already run Amadeus recovery and compensation tooling. Nexa is designed to sit next to them, not to replace them — see Airline disruption products.
Onboarding checklist
- Airline requests a Nexa access point and office / sign-in from Amadeus under its Altéa contract.
- Confirm the Altéa packages in scope (Reservation, DCS Customer Management, flight information, queues).
- Agree the transaction ceiling (TPS) and expected annual volume with Amadeus using the model above.
- Agree whether remark write-back is enabled, and the remark format.
- Agree where re-accommodation outcomes come from (PNR re-read, queue, or push).
- Certification in the Amadeus test environment, then production credentials and switch from mock to live.
Where to next
- Data requirements — the canonical fields Nexa reads.
- Airline disruption products — how Nexa works alongside recovery, compensation, and notification tooling you already run.
- How Nexa builds your connectors