MQTT via Websockets are preferred rather than making many many many queries. It's a good idea to use websockets rather than polling our APIs.

An example reference implemented is available in our a python SDK. https://github.com/projecthorus/pysondehub

The following API will provide the URL to the websockets API - https://api.v2.sondehub.org/sondes/websocket

Connections are WSS MQTT - use a unique client ID per connected client and please prefix the client ID with something unique to your app. Also ensure that compression is working on the websocket connections.

Data transfer costs SondeHub. Rather than having each client connect to SondeHub directly consider running a proxy/mirror of the data for your users. Also try to use per message deflate option for compression.

Topics

Batch topics

Prefer using these where possible

• batch Batch arrays of sonde telm data (preferred when trying to get all sonde data)
• batch-listener Batch arrays of sonde receiving station data
• batch-amateur-listener Batch arrays of amateur listener data
• batch-amateur Batch arrays of amateur telm

Slow/new feeds

These feeds provide newly seen sondes/balloons and listeners. They should be a slower feed rate than the ones below. They guarantee one or more delivery of the first packet seen by a payload. Deduplication is required on the client side.

• sondes-new/#
• listener-new/#
• amateur-new/#
• amateur-listener-new/#

Specific topics

• sondes/# All sondes
• sondes/{serial} a specific sonde
• listener/# All stations
• listener/{station name} a specific station
• amateur/# All amateur payloads
• amateur/{callsign} a specific amateur payload
• amateur-listener/# All amateur stations
• amateur-listener/{station name} a specific station

Prediction topics

• prediction/{serial} a specific sondes predictions (preferred)
• reverse-prediction/{serial} a specific sondes predictions (preferred)
• prediction/# all predictions - try to avoid
• reverse-prediction/# all reverse predictions