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.
This page explains the pattern that makes that sustainable, what every connector is made of, and what the delivery looks like week by week.
The pattern: ports, adapters, and one canonical model
The Nexa core — case orchestration, hotel allocation, rebooking, payments, transport, notifications — never talks to an external system directly. It talks to ports: small, stable, typed interfaces such as "give me the manifest for this flight", "give me this PNR", "tell me what happened to this flight", or "write this remark back to the booking".
Each external system is plugged into a port by an adapter — one per system — that translates between that system's protocol and payloads and Nexa's canonical data model.
The consequences are what matter to you:
- Your systems stay as they are. Nexa never asks an airline to migrate, re-platform, or expose a system in a new shape. If a system has an API, the adapter calls it. If it only exports files, the adapter reads files. If a vendor integrates on its own terms, the adapter is built to that vendor's process.
- Vendor change is contained. When your PSS renames a status code or versions its API, one adapter changes. Nothing else in the platform notices.
- One integration model for everything. Hotels, payment cards, messaging, ground transport, and airline systems all follow the same pattern, so the resilience, security, and audit guarantees are identical across all of them.
- Adding a system is additive. A new connector registers against an existing port. It does not edit the core.
What every connector is made of
Every connector is built on the Nexa connector SDK, which gives each adapter the same set of guarantees out of the box — they are not re-implemented per integration.
| Building block | What it guarantees |
|---|---|
| Typed port contract | The adapter implements a versioned interface. A connector that does not satisfy it does not compile, and so does not ship. |
| Canonical translator | Vendor payloads are mapped onto the canonical model, including vocabularies (cabin codes, loyalty tiers, SSR codes, status tokens) through reviewed dictionaries. |
| Mock twin | Every adapter ships with a deterministic mock implementing the same port. Your sandbox tenant runs end to end before a single production credential exists. |
| Mode switch: mock → live | The same code runs against the mock and your live system; only the credentials differ. Going live is a tenant setting, not a new code path. |
| Health probe + integration descriptor | Each connector reports its mode, whether credentials are present, and its health — without ever exposing a secret. Visible to your administrators in the console. |
| Platform-wide traffic shaping | Your system's published rate limits are enforced across the whole platform, so a large disruption never floods your PSS. |
| Circuit breaker + retries | Failures fail fast and are isolated per system; retries happen in durable workflows, never in a user's request. |
| Idempotency | Every inbound message is recorded once. Replays and duplicates never create a second disruption or a second booking. |
| Freshness verdicts | Every record carries its age against an agreed maximum staleness. Stale data is shown as stale, never silently served. |
| PII discipline | Sensitive identity data (documents, dates of birth) is tokenized at the adapter boundary; plaintext never enters the core. |
| Audit trail | Every call, every mapping decision, and every write-back is attributable and retained per your compliance regime. |
Connection channels
A connector can use whichever channel your system actually offers. Several channels can be combined for the same airline, and they all land on the same canonical contract.
| Channel | When it fits | Example |
|---|---|---|
| Pull (Nexa calls your API) | Your system exposes an API for reservations, manifests, or flight status. | Fetch the manifest for a disrupted flight; read a PNR; read the day's schedule. |
| Push (your system calls Nexa) | Your system can emit webhooks or call an endpoint on an event. | Your DCS or operations system posts a cancellation to the Partner API. |
| Event stream | Your integration layer already publishes an operational event stream. | Nexa subscribes to flight-movement and status events. |
| File exchange | The system has no API, or integrates only through exports. | Manifest exports from a DCS, uploaded by an agent or dropped on a scheduled feed. See File-based intake. |
A disruption never depends on a single channel. If a system is slow to certify, a file or push channel carries go-live while the pull connector is completed.
Delivery process
| Phase | What happens | Your side | Typical duration |
|---|---|---|---|
| 1. Discovery | Nexa reviews your system documentation and sample payloads or files, and maps each field to the canonical model. | Share API docs / sample exports; name a technical contact. | Days |
| 2. Interface control document | A written agreement per system: channel, endpoints or file layout, field mapping, vocabularies, rate limits, freshness targets, error handling. | Review and sign off. | 1 week |
| 3. Build against the mock | The adapter is built on the SDK and its mock twin is seeded with your real shapes, so your sandbox tenant shows your flights and manifests end to end. | Optional: review in the sandbox console. | 1–3 weeks |
| 4. Sandbox certification | The adapter runs against your test environment. A certification suite replays real scenarios: cancellations, diversions, delays, connections, groups, special needs, corrections. | Provide test credentials / test environment access. | 1–2 weeks |
| 5. Go-live | Production credentials are loaded into your tenant's isolated secrets namespace; the tenant is switched from mock to live and monitored through the first live disruptions. | Provide production credentials; confirm cut-over window. | Days |
| 6. Operate | Nexa monitors connector health, absorbs vendor changes, and handles version upgrades of your systems. | Notify Nexa of planned system upgrades. | Ongoing |
For a system with a documented API, phases 1–5 typically take 3–6 weeks. A push-only or file-based start can be live in days, with the pull connector following.
Who owns what
| Responsibility | Nexa | Airline |
|---|---|---|
| Adapter code, tests, certification suite | ✔ | |
| Mapping to the canonical model | ✔ | Reviews and approves |
| Hosting, monitoring, on-call for the connector | ✔ | |
| Absorbing vendor API changes | ✔ | Gives notice of planned upgrades |
| System documentation, test and production access | ✔ | |
| Commercial enablement with the system vendor, where the vendor requires it | Supports | ✔ |
Where to next
- Data requirements — exactly which data Nexa needs from the PSS, DCS, and operations systems, and why.
- Airline systems (PSS / DCS) — the airline-side connectors in detail.
- Operations & scheduling systems — flight status and disruption signals from your own operations tools.
- File-based intake — for systems that integrate through exports.