📄️ API Reference Overview
Nexa exposes three distinct API surfaces, each tailored to its audience and load shape. They share the same platform behind them but have different authentication, rate limits, and contracts. Pick the one that matches your integration.
📄️ Authentication
Nexa has three distinct identity surfaces. Each maps to one API surface and uses a different authentication mechanism. Mixing them is the most common integration mistake — read this page once before writing any auth code against the platform.
📄️ Operator API
The Operator API is the primary surface that powers the Nexa operations console. It is an API Composition / Backend-For-Frontend (BFF) that aggregates per-domain services (cases, booking, policies, wallet, notifications, audit, …) into a single operator-shaped surface, plus a real-time WebSocket presence channel for the operator swarm.
📄️ Passenger API
The Passenger API is the read-optimized surface that powers the passenger-facing mobile webapp. It is the CQRS read side of Nexa: every read is served from a denormalized snapshot store fully isolated from the operational cases database, so the tens of thousands of refreshes a Tier-1 hub closure generates cannot impact the operator UI.
📄️ Partner API
The Partner API is the third BFF surface alongside operator and passenger. It targets B2B integrators — airline systems, corporate travel desks, OTAs, ground-handling agents, regulators — who need to call Nexa programmatically.
📄️ Webhooks
Webhooks come in two flavors at Nexa:
📄️ OpenAPI Specification
Every Nexa API surface publishes a live OpenAPI 3.1 specification. Use it to generate SDKs, drive contract tests, and explore endpoints interactively.