ποΈ Integrations Overview
Nexa is a hub between airlines, partners, and passengers. Every external system sits behind a typed adapter, so the orchestration layer never sees partner-specific JSON or has to know whether it's calling Amadeus or a sandbox endpoint.
ποΈ How Nexa Builds Your Connectors
Integrating a disruption platform usually means the airline's IT team learning a new API, writing a translation layer, and maintaining it forever. Nexa inverts that. Nexa builds, certifies, and operates the connector to your systems. Your team shares documentation and access; the adapter that speaks your PSS, DCS, or operations system is Nexa's code, on Nexa's release train, under Nexa's on-call.
ποΈ Data Requirements (PSS / DCS / Ops)
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.
ποΈ 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.
ποΈ Amadeus AltΓ©a Connector (PSS / DCS)
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.
ποΈ Working With Your Disruption Products
Many airlines already run tooling for parts of a disruption hotels, meals, ground transport, and the operators who coordinate them.
ποΈ Operations & Scheduling Systems
A disruption starts with a flight
ποΈ File-based Intake (Systems Without an API)
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.
ποΈ Amadeus
Nexa integrates with Amadeus Self-Service APIs for hotel inventory search and booking. Amadeus is the largest GDS and one of the two primary inventory sources for the platform (the other is Hotelbeds).
ποΈ Hotelbeds
Nexa integrates with Hotelbeds APITUDE as the second of two primary hotel inventory sources (alongside Amadeus). Hotelbeds is a bedbank with deep coverage of leisure-focused properties; it complements Amadeus's GDS-centric catalog.
ποΈ Direct Contracts
Tenants frequently negotiate direct contracts with hotel chains for guaranteed rates and inventory during disruption events. Nexa surfaces these contracts as a first-class inventory source alongside Amadeus and Hotelbeds, with the same scatter-gather search semantics and the same booking pipeline.
ποΈ Pomelo (Wallet)
Nexa integrates with Pomelo as the primary issuer for virtual prepaid cards distributed to disrupted passengers. Cards cover meal allowance, sundries, and (per policy) incidentals during the disruption β a far better passenger experience than paper meal vouchers, with full transaction visibility and tight control over spend rules.
ποΈ Flight Data (AeroAPI & friends)
Nexa's flight-predictor consumes real-world flight data from multiple sources to detect disruptions, predict cancel/delay risk, and trigger case provisioning automatically. Unlike the booking and wallet integrations (which are tenant-scoped), the flight predictor is a shared platform service β it consumes public flight + weather data with no PII, and serves every tenant from a single deployment.
ποΈ Notifications (Twilio, SendGrid, WhatsApp)
Nexa delivers notifications to passengers and operators across multiple channels, with delivery telemetry from each. The notifications domain is the single outbound communication surface for the platform β every other domain enqueues a notification request; the notifications domain decides how it gets delivered.
ποΈ Ground Transport (Uber, Cabify)
When a disruption requires ground transport between the airport and the hotel β or between the hotel and the next-flight airport β Nexa orchestrates the transfer through ride-hailing or contracted transport vendors. The transport domain is the saga participant on the transport leg, with the same idempotency and async behavior as booking.