Skip to main content

Welcome to Nexa

Nexa is a fully-managed B2B SaaS platform that orchestrates passenger re-accommodation — hotels, ground transport, meals, and communications — when flights are delayed, cancelled, or rescheduled. Airlines integrate by sending HTTPS requests to a regional endpoint; their operations teams work in the console; and their passengers receive offers on a mobile web app linked from SMS, email, or WhatsApp. There is nothing to install on either side.

What Nexa does​

When an airline reports a disruption, Nexa:

  1. Ingests the event — the disrupted flight, the passenger manifest, tier (Economy / Premium / Business / Crew), and the next scheduled re-accommodation. The airline supplies the next flight; Nexa does not compute it.
  2. Opens a case and provisions sub-cases — one per Passenger Name Record (PNR), grouping families together. Manifest fetch goes through the per-airline PSS adapter (Amadeus, Sabre, custom).
  3. Searches inventory in parallel — across Amadeus, Hotelbeds, and any directly-contracted hotels, with a hard 2-second time-box. The aggregator returns whatever has answered; partial results beat UI freezes.
  4. Allocates rooms — a deterministic multi-objective scorer (cost dominant, with distance and consolidation penalties) ranks candidates per tier and respects per-tenant policies.
  5. Books asynchronously — through the selected vendor, behind a per-vendor cluster-wide token bucket, with automatic retries, fallbacks, idempotency keys, and saga compensation if any leg fails.
  6. Issues a virtual prepaid card when the policy authorizes meal allowance or incidentals — single-load or scheduled drops (breakfast → lunch → dinner).
  7. Notifies every passenger with a localized voucher (hotel QR, address, transport, card details) over SMS, email, and WhatsApp.
  8. Lets passengers accept or decline the offer from their phone. Declines trigger automatic saga rollback — the room is released, the operator is alerted in real time, and the sub-case re-enters rework.
  9. Escalates exceptions — stockouts, vendor failures, policy conflicts — to a manual-review queue with AI-generated recommendations that operators can accept, edit, or reject.

Every step is auditable, resumable, and driven by operator-editable policies.

Architectural pillars​

Nexa is engineered to survive operational panic — the microscopic windows during a Tier-1 hub closure where dozens of agents and tens of thousands of passengers hit the platform simultaneously. Four patterns make this possible:

  • Event-driven async workflows — every cross-domain interaction and every partner call goes through an asynchronous workflow. Operators never wait on Amadeus; the booking workflow does.
  • Read-side isolation for passenger reads — passenger-side traffic reads from a denormalized snapshot store, fully isolated from the operational case database. Tens of thousands of refreshes from anxious passengers cause zero contention with the operator UI.
  • Distributed coordination — the operator UI uses presence-driven entity locks so two operators can't edit the same passenger; the booking engine uses per-attempt soft-holds with self-healing expiry so two operators can't double-book the same hotel room.
  • Anti-corruption adapters — every external partner (Amadeus, Hotelbeds, Pomelo, Twilio, SendGrid, AeroAPI, Uber, Cabify, Meta WhatsApp Business) sits behind a typed adapter. The orchestration layer never sees partner-specific data shapes.

The full design narrative is in How Nexa survives operational panic. The infrastructure-level story — multi-region availability, global edge, layered backoff — is in How Nexa stays available.

Where to start​

What Nexa does NOT do​

  • Compute next flights or re-accommodation routes. The airline's PSS supplies the next-flight payload. Nexa allocates hotels and pays for them; it does not rebook tickets.
  • Hold inventory long-term. Soft-holds expire automatically. There is no shared mutable counter that can drift.
  • Confirm a booking with an LLM. AI agents are scoped to exception triage with an explicit tool allow-list — never irreversible operations (booking confirmation, payment capture).
  • Persist toxic PII. Passport / DNI documents stay in the airline's system of record. Nexa stores reference URNs.
  • Cross tenants. A token issued for urn:airline:latam cannot read a case owned by any other airline. Tenant isolation is enforced at the JWT, the application layer, and the database.

Platform pillars​

Nexa combines Nexa Trained Models (a flight-disruption predictor, an allocation scorer, a policy synthesizer, and an exception agent) with a provider abstraction that lets operators swap inventory sources, email/SMS providers, and payment processors without touching business logic.

Where Nexa's models fit in​

  • Flight-disruption predictor — a dual-head model (cancel probability + delay minutes) trained on weather, labor, traffic, airport operations, destination, and seasonality. Used to size demand ahead of the event and to flag at-risk airports. See Flight Predictor.
  • Allocation scorer — a deterministic multi-objective scorer (cost dominant, with distance and consolidation penalties) that ranks hotel candidates per tier. See Allocation engine.
  • Policy synthesizer — an AI-driven assistant that converts natural-language descriptions ("Business tier needs 4-star, within 15 km, 24-hour room service") into a structured, versioned policy. See Policies.
  • Exception agent — an AI agent with a strict tool allow-list that triages stuck cases, proposes alternative hotels or policy relaxations, and writes the justification the supervisor approves. See Exception agent.

Integrations at a glance​

  • Hotel inventory & booking: Amadeus Self-Service, Hotelbeds APITUDE, in-house direct contracts.
  • Virtual prepaid cards: Pomelo (issuer; OAuth2 + HMAC-signed webhooks).
  • Flight data: AeroAPI, AviationStack, FlightAware (selective).
  • Email / SMS / WhatsApp: SendGrid, Twilio, Meta WhatsApp Business.
  • Ground transport: Uber, Cabify.
  • AI: Nexa-trained models hosted on a major hyperscaler's managed AI platform — used only for the policy synthesizer and exception agent (never for irreversible operations).
  • Identity: OIDC-based identity with JWT and role-based access for ADMIN, OPS_SUPERVISOR, AIRPORT_OPERATOR, FINANCE_AUDIT, and passenger-facing roles.

Every external integration sits behind an interface-typed adapter, so the orchestration layer never knows whether it is talking to a live vendor or a sandbox endpoint.

Getting help​

Was this helpful?