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:
| Region | Base URL |
|---|---|
| us-central1 (default) | https://us-central1.api.nexastudio.io |
| europe-west1 | https://europe-west1.api.nexastudio.io |
| southamerica-east1 | https://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
- Email sales@nexa.ai to provision a tenant.
- After provisioning, the operations console at ops.nexa.ai is available for your
ADMINusers. - 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:
| Role | Typical use |
|---|---|
ADMIN | Tenant admin: policies, integrations, role assignments, audit export. |
OPS_SUPERVISOR | Approves demand, overrides allocations, resolves manual-review items. |
AIRPORT_OPERATOR | Day-to-day operator scoped to an airport (or list of airports). |
INTEGRATION | Server-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-RemainingandRetry-After. - Idempotency is built in for the disruption ingest endpoint: every POST to
/casesmust include anexternalEventId(or anIdempotency-Keyheader). Replays return the samecaseUrninstead 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.