Skip to main content

API Access

Nexa is a fully-managed SaaS. There is nothing to install or operate on your side — airlines and operations teams consume the platform through HTTPS endpoints and the operations console at ops.nexa.ai. This page covers everything you need to make your first authenticated call.

Base URLs

The Nexa API is deployed regionally. Pick the region closest to your operations center:

RegionBase URL
us-central1 (default)https://us-central1.api.nexastudio.io
europe-west1https://europe-west1.api.nexastudio.io
southamerica-east1https://southamerica-east1.api.nexastudio.io

All examples in these docs use https://us-central1.api.nexastudio.io. Multi-region tenants get a single virtual host (https://api.nexastudio.io) that routes to the closest replica.

Get credentials

  1. Email sales@nexa.ai to provision a tenant.
  2. After provisioning, the operations console at ops.nexa.ai is available for your ADMIN users.
  3. From the console: Settings → API Tokens → Generate issues a service token scoped to a role and (optionally) a single airport or airline ICAO.

The token is a JWT bearer. Keep it in a secret manager — Nexa never displays it twice.

Authenticate every request

export NEXA_BASE_URL="https://us-central1.api.nexastudio.io"
export TOKEN="<paste your service token>"

curl -sS "$NEXA_BASE_URL/version" \
-H "Authorization: Bearer $TOKEN"

A successful call returns the deployed build hash and the API version:

{
"build": "2026.04.0+a1b2c3d",
"apiVersion": "v1",
"region": "us-central1"
}

If the token is missing or expired you get 401 Unauthorized; if the role does not match the requested resource you get 403 Forbidden. See Roles & RBAC.

Roles you can request

Service tokens are minted for one of four roles:

RoleTypical use
ADMINTenant admin: policies, integrations, role assignments, audit export.
OPS_SUPERVISORApproves demand, overrides allocations, resolves manual-review items.
AIRPORT_OPERATORDay-to-day operator scoped to an airport (or list of airports).
INTEGRATIONServer-to-server token for the airline's disruption webhook → Nexa.

Pick the least privileged role that satisfies your integration. The Quick Start uses INTEGRATION to post events and OPS_SUPERVISOR to approve them.

Rate limits and idempotency

  • Rate limits are per-tenant per-route. The default is 600 RPM for read endpoints and 120 RPM for write endpoints. The response includes X-RateLimit-Remaining and Retry-After.
  • Idempotency is built in for the disruption ingest endpoint: every POST to /cases must include an externalEventId (or an Idempotency-Key header). Replays return the same caseUrn instead of creating a duplicate. See Idempotency.

Webhook from the airline DCS

Airlines typically configure their Departure Control System or IROPS workbench to POST disruption events to Nexa. We accept the same payload you saw in POST /cases:

curl -X POST "$NEXA_BASE_URL/cases" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d @disruption-event.json

There is no installer, no agent, no on-prem footprint — your DCS or middleware sends one HTTPS request and Nexa takes it from there.

Operations console

The console at ops.nexa.ai is the same multi-tenant SaaS, surfaced for humans:

  • Live cases dashboard
  • Demand approvals and manual review queues
  • Policy editor (with the natural-language synthesizer)
  • Allocation explainer (cost / distance / consolidation breakdown)
  • Audit export (CSV / JSONL)

Every action in the console is exactly equivalent to a call against the API — operators and integrations share the same audit trail.

Where to next

  • Quick Start — drive a disruption from event to voucher in 10 minutes against a sandbox tenant.
  • Providers overview — what Nexa connects to, what's tenant-managed vs. Nexa-managed, and rate-limit behavior.
  • Author a policy — encode hotel-selection rules per tier and airport.
  • RBAC & Roles — what each role can and cannot do.
Was this helpful?