Skip to main content

Multi-tenant & Isolation

Nexa is a multi-tenant SaaS. Every airline (and, for groups and alliances, every member carrier) is provisioned with its own tenant — the isolation boundary for cases, passengers, policies, allocations, contracts, audit, and billing. This page describes the isolation guarantees customers can rely on.

What a tenant is​

A tenant is the unit of isolation. Each tenant has:

  • Its own users and RBAC scopes.
  • Its own policies, direct-contract inventory, and notification branding (logo, colors, sender address).
  • Its own credentials for upstream providers (Amadeus, Hotelbeds, SendGrid, PSP).
  • Its own data partition — case, passenger, reservation, and audit records carry the tenant identifier and never leak across tenants.

Single-airline customers have one tenant. Holding groups and alliances have one parent tenant per member carrier; cross-tenant reporting (for the parent) is opt-in.

How requests are isolated​

Every JWT issued by Nexa carries a tenant claim. The API:

  1. Reads tenant from the bearer token.
  2. Pins the database connection's default filter to that tenant.
  3. Blocks cross-tenant URNs — a request for urn:nexa:case:xyz from tenant A returns 404 Not Found if that case belongs to tenant B, regardless of the role.

Isolation is enforced at the persistence layer, not just the controller — even an internal bug that forgot to filter would still return 404 for cross-tenant access. Nexa runs an automated cross-tenant test suite on every release.

Per-tenant configuration​

A tenant admin can configure, via the operations console:

  • Branding: logo, primary color, sender address and display name on vouchers.
  • Providers: which hotel/email/payment providers are active for this tenant, plus the credentials.
  • Predictor: which ICAOs the flight predictor is observing.
  • Policies: per-tier hotel-selection rules (see Policies).
  • AI features: toggle the exception agent and policy synthesizer per tenant.
  • Identity: SSO / SAML / OIDC integration with the airline's IdP (Okta, Azure AD, Auth0).

Provider credentials are stored in Google Secret Manager, encrypted at rest, scoped per tenant, and never returned in any API response.

Shared infrastructure, isolated data​

Nexa uses shared compute for cost and operational simplicity, but every byte of customer data is partitioned:

  • Database: a single logical database with tenant fields on every collection. All queries filter by tenant in middleware.
  • Background queues: shared workers, but jobs carry tenant and the worker re-asserts the filter before reading or writing.
  • Audit: shared storage, partitioned by month and filterable by tenant. Tenants only see their own audit entries.

For airlines that need stronger isolation (single-tenant compute, dedicated database, or regional residency), Nexa offers single-tenant deployments — contact sales@nexa.ai.

Roles within a tenant​

A user can belong to multiple tenants with different roles per tenant — useful for ground-handling agents serving multiple carriers. The IdP carries the membership; Nexa maps IdP groups to roles. See Roles.

Onboarding a new tenant​

Onboarding is run by Nexa's customer success team:

  1. Provision the tenant (region, airports, RBAC mapping).
  2. Wire your IdP (Okta / Azure AD / OIDC group → Nexa role mapping).
  3. Configure providers (Amadeus / Hotelbeds / SendGrid sub-user / PSP).
  4. Load direct contracts and seed the initial policy set.
  5. Smoke-test against the sandbox tenant with synthetic disruptions.
  6. Promote to production.

Typical onboarding completes in 1–3 weeks depending on provider credential turnaround on your side.

Isolation guarantees you can audit​

  • Cross-tenant queries return 404 Not Found.
  • Audit pages filter by tenant.
  • Notifications use the tenant's SendGrid sub-user and templates.
  • Voucher templates use the tenant's branding.
  • Provider credentials are per-tenant (not shared).
  • PSP tokens are per-tenant (not shared).
  • Predictor configuration and outputs are per-tenant.

Tenants on a regulated compliance posture get the cross-tenant test report as part of every quarterly attestation.

Was this helpful?