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.

What Nexa connects to

Category	Partners
Airline systems (PSS / DCS)	Amadeus Altéa, Sabre PSS, Navitaire, custom in-house
Hotel inventory & booking	Amadeus Self-Service, Hotelbeds APITUDE, direct contracts
Virtual prepaid cards (wallet)	Pomelo
Flight data & disruption signals	AeroAPI, AviationStack, FlightAware
Communications	Twilio (SMS), SendGrid (email), Meta WhatsApp Business
Ground transport	Uber, Cabify
AI	Nexa-trained models — policy synthesis, exception agent (Nexa-managed)
Identity	Nexa-managed identity for operators and machine-to-machine; Nexa-issued passenger sessions

The flight predictor is a Nexa Trained Model; we don't expose third-party LLM APIs to customers.

How Nexa integrates with partners (the architectural pattern)

Every partner sits behind an interface-typed adapter. The orchestration layer only ever sees Nexa's canonical data model — generic shapes for inventory search, voucher fulfillment, wallet card summaries, and flight disruption signals. Partner-specific types never leak past the adapter. If a partner changes a rate-code taxonomy or a status enum, the adapter absorbs it; the rest of the platform doesn't notice.

Every adapter ships with a mock counterpart. Sandbox environments work without partner credentials.

URN-routed dispatch

Every partner-issued identifier carries the partner structurally:

urn:hotel:SCL1234:vendor:amadeus
urn:reservation:r-8842:vendor:hotelbeds:status:confirmed
urn:auth:auth-9912:vendor:pomelo

The booking engine dispatches by reading the partner from the URN, rather than maintaining an explicit if/else chain or a side providerName field. Adding a new partner adds one entry to the registry, not edits across the codebase.

Resilience primitives every integration uses

Three engineering primitives, applied uniformly across every partner:

Adaptive traffic shaping per partner

Nexa enforces each partner's published rate limit at the platform level, not per-process. Per-process limiters break under autoscaling — the moment worker capacity scales out, each process believes it has the full budget and the platform exceeds it. The platform-wide approach guarantees the configured rate is the actual rate, regardless of replica count.

Workers wait for budget rather than calling and getting rate-limited. The queue absorbs surges; the autoscaler reacts to depth, never bursts the partner.

Circuit breakers

Every synchronous partner call is wrapped in a circuit breaker.

• Tight timeout that fails fast rather than tying up resources.
• Failure threshold that opens the circuit when error rate spikes.
• Open state returns 503 Service Unavailable with Retry-After. The operator UI surfaces "Booking system unavailable — wait and retry." It does not auto-retry; that is what the breaker is preventing.
• Half-open recovery allows a probe after a cool-down. Success closes the breaker; another failure re-opens it.
• Per-partner isolation — an outage at one partner does not disable a different partner. Telemetry on every state change feeds the on-call dashboard.

Retry semantics

Retries happen in the workflow layer, never in the operator-facing HTTP path. Exponential backoff with per-domain budgets, then a route to the operator's manual-review queue once the budget is exhausted. The operator sees a clear "vendor cancel failed — please reconcile" indication and acts accordingly.

Tenant-managed vs Nexa-managed

Some partner credentials are per-tenant — the airline contracts directly with the partner, and Nexa stores the credentials in the tenant's secrets namespace. Others are Nexa-managed — Nexa contracts with the partner on behalf of all tenants and absorbs the cost.

Partner	Credentials	Cost
Airline PSS / DCS (Altéa, Sabre, Navitaire, custom)	Tenant-managed (the airline's own system)	No partner cost — it is the airline's system
Amadeus	Tenant-managed	Tenant pays partner directly
Hotelbeds	Tenant-managed	Tenant pays partner directly
Pomelo	Tenant-managed	Tenant pays partner directly (issuer fees + interchange)
Twilio	Tenant-managed (per-tenant phone numbers)	Tenant pays partner directly
SendGrid	Nexa-managed (shared)	Pass-through line item on Nexa invoice
Meta WhatsApp Business	Tenant-managed (per-tenant phone numbers)	Tenant pays partner directly
Uber / Cabify	Tenant-managed	Tenant pays partner directly
AeroAPI / AviationStack / FlightAware	Nexa-managed (shared)	Bundled in the Nexa subscription
AI provider	Nexa-managed	Bundled in the Nexa subscription
Identity provider	Nexa-managed	Bundled in the Nexa subscription

The Nexa-managed line items appear at scale on the platform invoice, not the per-disruption invoice — they are infrastructure costs, not per-event costs.

Onboarding a tenant-managed partner

For each tenant-managed integration, the airline provides credentials via a Customer Success-led onboarding:

1. Airline procures credentials (Amadeus production credentials, Hotelbeds APITUDE keys, Pomelo affinity-group config, Twilio number, etc.).
2. Nexa loads them into the tenant's secrets namespace.
3. Nexa runs adapter health checks against the partner's sandbox, then production.
4. Customer Success flips the tenant flag from mock to live.

The same adapter code runs against mock and live; the only difference is the credentials. There is no separate "live mode" code path.

Where to next

• Airline systems — PSS / DCS adapter for Altéa, Sabre, Navitaire, and custom in-house systems.
• Amadeus — hotel inventory + booking via Amadeus Self-Service.
• Hotelbeds — bedbank inventory + booking via APITUDE.
• Direct contracts — in-house pre-negotiated hotel deals.
• Pomelo — virtual prepaid cards.
• AeroAPI & flight data — disruption signals and flight state.
• Notifications — Twilio, SendGrid, WhatsApp Business.
• Transport — Uber, Cabify.