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.nexastudio.io. 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
North America (default)https://na.api.nexastudio.io
Europehttps://eu.api.nexastudio.io
South Americahttps://sa.api.nexastudio.io

All examples in these docs use https://na.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 [email protected] to provision a tenant.
  2. After provisioning, the operations console at ops.nexastudio.io 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://na.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": "na"
}

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.nexastudio.io 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.
  • Integrations 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?