MQTT (IoT Broadcast)

For IoT subscribers that want to receive your broadcast channels without integrating our SDK. Standard MQTT over TLS on mqtts://mqtt.droponair.com:8883, subscribe-only, per-app credentials. The platform mirrors every broadcast fan-out to a corresponding MQTT topic so devices that already speak MQTT can ride the lane natively.

Topic shape

droponair/v1/broadcast/<appId>/<channelId>

Payload is the raw protobuf BroadcastNotification bytes, identical to what SDK clients receive over WebSocket / SSE / WebTransport. QoS 0, retained=false. Bring your own protobuf decoder using the schema published with the SDK.

Credentials

Each customer app gets a dedicated MQTT username (the app's appId) and a shared secret issued from the dashboard. The ACL restricts each username to its own droponair/v1/broadcast/<appId>/# subtree, no publish path, no cross-tenant access. Email support@droponair.com to request MQTT access for your app.

Subscribe (mosquitto_sub example)

mosquitto_sub   -h mqtt.droponair.com -p 8883   --capath /etc/ssl/certs   -u "<appId>" -P "<shared-secret>"   -t "droponair/v1/broadcast/<appId>/#" -v

Why this exists

Some IoT fleets (ESP32 nodes, low-power microcontrollers, vendor MQTT gateways) cannot embed our SDK. Exposing broadcasts on MQTT lets them consume real-time updates from your app without the SDK surface, without WebSocket, and without bespoke gateway code on your end. SDK-bearing clients continue to use WebSocket / SSE / WebTransport as before.

Verify the lane is live via GET /api/info.transports (must include "mqtt") and features (must include "transport_mqtt").