UDAI Documentation
Technical reference for the Unified Drone Airspace Interface (UDAI), the shared registry and coordination layer for low-altitude airspace in India. This site specifies the organisation, asset, mission, flight plan, airspace zone, permission, and telemetry surfaces of the platform, and is the reference of record for integrators.
Developed by Drone Federation India (DFI). Hosted by Airports Authority of India (AAI). Product overview: udai.live .
Contents
| Section | Purpose |
|---|---|
| UDAI | Concept and principles, architecture, governance, standards, and use cases |
| Data models | Canonical entities, their relationships, and integer dictionaries |
| APIs | REST and WebSocket surfaces, access rules, and response envelopes |
| Integration Kit | Worked sequence from asset registration to telemetry ingest |
| About | Institutions, steering, licensing, security, privacy, and support |
Audience
| Reader | Primary reference | Supporting references |
|---|---|---|
| Integrators building ground control, fleet, or mission planning software | Integration Kit | Sandbox, API overview |
| Airspace authorities publishing zones and deciding permissions | Airspace zones | Airspace awareness, Access control |
| Institutions assessing UDAI before integration | Concept and principles | Architecture, Governance |
| Implementers mapping an existing schema onto UDAI | Data models | Enums |
Integration sequence
The sequence is ordered. Each step consumes identifiers returned by the preceding step. Request and response bodies are given in the Integration Kit.
| Step | Call | Reference |
|---|---|---|
| 1 | POST /assets: register an aircraft against an existing asset model | Assets |
| 2 | POST /users/invitations, then POST /users/{user_uuid}/pilot-creds: admit and credential a pilot | Users |
| 3 | POST /missions: file a mission envelope, window, assets, and pilots | Mission planning |
| 4 | POST /flight-plans?mission_uuid=...: file a flight plan inside the mission window | Flight planning |
| 5 | POST /flight-sessions, then MQTT or WebSocket ingest | Flight sessions, Telemetry wire contract |
A mission generates one Permission for every Airspace Zone its envelope intersects. Awareness and Green zones are approved on creation. All other zones remain Pending until an Airspace Manager decides them. Flight plans inherit mission permissions by reference.
No first-party SDKs are published. Integration is direct against the HTTP and WebSocket surfaces specified here.
Request headers
Requests to the surfaces documented here carry the following headers.
| Header | Value |
|---|---|
partner-api-key | Partner key issued for the target host |
Authorization | Bearer and an access token obtained per Authentication |
X-Organisation-ID | UUID of the organisation on whose behalf the call is made |
Content-Type | application/json |
Endpoint eligibility by organisation type and role is defined in Access control. Error and pagination envelopes are defined in Base URL and responses.
API hosts
| Environment | Base URL | Purpose |
|---|---|---|
| Sandbox | https://sandbox-api.udai.live/v1 | Integrator testing. Data may be reset |
| Staging | https://staging-api.udai.live/v1 | Pre-production checks |
| Production | https://api.udai.live/v1 | Live national operations |
All REST paths in this documentation are relative to /v1 on the selected host. Host policy is defined in Environments.
Access
Partner keys are issued, not self-service. Access requires:
- A registered organisation.
- At least one verified Admin or Owner user.
- Conformance with Standards and Interoperability.
- A sandbox partner key requested through a DFI or AAI integration contact.
Sandbox conditions are stated in Sandbox. Enquiries: Support.