Skip to main content

Welcome to Nexa

Nexa is a fully-managed SaaS platform that orchestrates hotel accommodation, transport, and passenger communications when flights are delayed, rescheduled, or cancelled. There is nothing to install — airlines integrate by sending HTTPS requests to a regional endpoint (for example https://us-central1.api.nexastudio.io) and operations teams work in the console. Nexa replaces spreadsheets, shared inboxes, and phone chains with a single policy-driven workflow that runs 24/7.

What Nexa does​

When an airline reports a disruption — a cancelled flight, a long delay, a reroute — Nexa:

  1. Ingests the event with passenger manifest, tiers (Economy, Business, First, Crew), and the next scheduled flight.
  2. Computes the stay plan (check-in, check-out, rooms needed) from the reaccommodation and policy buffers.
  3. Searches inventory in parallel across Amadeus, Hotelbeds, and any directly-contracted hotels, deduplicating results.
  4. Allocates rooms with a multi-objective scorer (cost → distance → consolidation) that keeps PNRs together and respects per-tier policies.
  5. Books through the selected provider with retries, fallbacks, and idempotency keys.
  6. Notifies every passenger with an HTML voucher (hotel, dates, next-flight details, transport).
  7. Escalates exceptions — stock-outs, provider failures, policy conflicts — to a manual-review queue with AI-generated recommendations.

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

Where to start​

  • Beyond the Transponder — the architectural thesis behind Nexa: airline-centric prediction, multi-agent intelligence, and graceful fallbacks. Start here if you want the why.
  • API Access — base URLs, regions, authentication, and rate limits.
  • Quick Start — drive a disruption from event to voucher in 10 minutes against a sandbox tenant.
  • Architecture — modules, queues, and the case lifecycle that powers Nexa.
  • Providers overview — see what Nexa connects to (hotel GDS, payment, email) and how onboarding works.
  • Disruption Dashboard — the live operational view of cancellations, delays and the predictor's reasoning.

Platform pillars​

Nexa combines Nexa Trained Models on Google (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 providers, and payment processors without touching business logic.

Where Nexa's models fit in​

  • Flight-disruption predictor — a dual-head Nexa Trained Model (cancel probability + delay minutes) trained on weather, labor, traffic, airport operations, destination and seasonality features. 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 — a Nexa AI agent 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 — a Nexa AI agent with a tool allow-list that triages stuck cases, proposes alternative hotels or policy relaxations, and writes the justification the supervisor approves. See Exception agent.

Integrations​

  • Hotel inventory: Amadeus Self-Service, Hotelbeds APITUDE, and in-house direct-contract inventory.
  • Hotel booking: Amadeus Hotel Orders, Hotelbeds Bookings.
  • Email / vouchers: SendGrid (with a limited sandbox channel for evaluation).
  • Payments: corporate-guarantee flows out of the box; PSP adapter points for card/tokenized billing.
  • AI: Nexa Trained Models on Google power the predictor, policy synthesizer, and exception agent — there are no third-party LLM APIs for the customer to provision.
  • Identity & roles: JWT-based RBAC for ADMIN, OPS_SUPERVISOR, AIRPORT_OPERATOR, and passenger-facing roles.

All external integrations sit behind interface-typed adapters so the orchestration layer never knows whether it is talking to a live GDS or a limited sandbox endpoint.

Getting help​

Was this helpful?