Air Quality Monitoring Data Platform APIs: Sensor to Dashboard
When Dana finished rolling out twelve air quality stations across a mid-sized city, the hardware did exactly what the specification promised. The sensors were accurate, and every enclosure survived a full winter.
Six weeks later, the public dashboard had become a running joke in council meetings. Half the readings were hours old, one district’s PM2.5 sat frozen at a single value for three days, and a local journalist had found two neighbourhoods reporting numbers that could not both be right.
The stations were fine. The air quality monitoring data platform and the API feeding it were not.
This is a common outcome, and it rarely comes down to the sensors. It comes down to a decision that gets made late and often by accident: how data travels from the station to the platform, and which API exposes it at the end.
By the end of this guide you will know the four ways to get air quality data into a platform, how the field-to-API chain actually works, which interoperability standards matter for municipal work, and which licensing and rate-limit traps decide whether a build survives contact with production. See how an outdoor IoT air quality monitoring station produces the raw readings →
Platform vs API: What Each One Actually Is
An air quality data platform ingests, stores, computes and visualises measurements from many stations. An air quality API is the programmatic interface (REST, MQTT or an open standard) through which another system reads or writes that data.
The two terms get used interchangeably, and that’s the first integration mistake. A platform is a destination. An API is a door. You can consume someone else’s API, expose your own, or do both at once, and each choice carries different costs and constraints.
There are really three data relationships to think about. You can consume a public aggregator’s API and get other people’s stations. You can own the stations and expose your own API to a city platform or an app. Or you can publish into a shared interoperability standard, so any compliant system reads your data without custom work.
Most real deployments blend all three, which is why the platform decision deserves to be made before the hardware is specified, not after it is installed.
The Field-to-API Chain: How Air Quality Data Reaches a Dashboard
An air quality monitoring data platform API doesn’t appear out of nowhere. Data passes through six stages before it reaches a screen, and knowing the chain tells you where a build can fail.
- Measure. The station’s sensors read particulate matter, gases and meteorology at the site.
- Normalise. A controller or gateway reads those sensors over RS485/Modbus (or I2C and UART internally) and converts raw counts into engineering units.
- Uplink. A gateway or edge computer converts the field protocol into a network payload and transmits over LoRaWAN, NB-IoT or 4G.
- Broker. An MQTT broker (Mosquitto, HiveMQ, EMQX or a cloud IoT service) receives the telemetry on topics such as
aq/{site}/{device}/telemetry. - Store and compute. A time-series database holds the readings, and a compute step applies quality control, correction and AQI conversion. The index maths itself lives elsewhere; see how the air quality index is calculated.
- Expose. A REST/JSON API, or a standard such as SensorThings or NGSI-LD, serves the data to dashboards, maps and third-party apps.
Where you can expose an API at every layer
The useful insight is that an API can be exposed at almost any stage. The Modbus register map is an interface at the device level; the MQTT topic is one at the transport level. REST/JSON sits at the application level, and SensorThings or NGSI-LD at the interoperability level. Pick the layer your consumer actually needs, and you avoid building three of them.
Store-and-forward isn’t optional outdoors
Field connectivity drops. Cellular dead zones, tower maintenance and power events all interrupt the uplink, and a station that simply stops reporting loses the very data it was installed to collect.
Gateways and edge terminals buffer readings locally, then re-upload the backlog once the link returns. That behaviour is the difference between a dataset with gaps and a dataset you can defend, which is why it belongs in the platform requirements, not the hardware afterthought. The connectivity behind that uplink is covered in NB-IoT vs LoRaWAN for smart city sensors.
Four Ways to Build an Air Quality Data Platform
There’s no single correct architecture. There are four approaches, and the right one depends on whether you own the sensors, who consumes the data, and whether an interoperability mandate applies.
| Approach | What it is | Effort | Cost model | Best fit |
|---|---|---|---|---|
| A. Consume a public API | Use OpenAQ, AirNow, PurpleAir, Google or aqicn/WAQI | Very low | Free to per-request | Coverage gaps, reference context, rapid prototypes |
| B. Self-host open source | Mosquitto/HiveMQ + Node-RED + InfluxDB/TimescaleDB + Grafana | Medium to high | Infrastructure plus staff time | Full control, private data, modest budgets |
| C. Buy a commercial platform | ThingsBoard, FIWARE-based brokers, vendor SaaS | Low | Subscription or licence | Fast time to value, fleet management, support |
| D. Expose your own device API | Publish your fleet’s data as REST, MQTT or a standard | Medium | Engineering time | You own the stations; a city platform or app consumes it |
Option D is the one nobody writes about, yet it’s the correct choice whenever the stations are yours and the consumer is a city platform, a compliance file or a public app. The other three options rent someone else’s infrastructure or data. Option D builds an asset.
A quick decision path helps. Do you own the sensors? If not, start with A. Is the data private, or does data sovereignty apply? Both push you to B or D. Is there a municipal interoperability mandate? That points to D with a standard. Finally, compare the three-year cost of ownership, not just the first invoice.
A quick story about mixing options
Priya, a sustainability consultant in Dubai, needed city-wide PM2.5 for a client report but only had three of her own stations. She consumed OpenAQ for broad coverage, used her own stations for local validation, and published the combined result through her own lightweight API. One platform, three data relationships, and no single vendor holding the keys. That hybrid is the norm, not the exception.
Open-Source Stack vs Commercial Platform: Anatomy of Each
Approaches B and C are the two most common, and they differ mostly in who carries the operational burden.
The open-source reference stack
A self-hosted build is assembled from parts that are individually boring and collectively capable. A broker such as Mosquitto, HiveMQ or EMQX handles ingest. Node-RED handles flow logic. InfluxDB or TimescaleDB stores the time series, and Grafana renders the dashboards.
Kapacitor or Alerta handles alerting, and containers on Docker or Kubernetes tie the parts together. A small municipality in France runs exactly this pattern for its LoRaWAN environmental sensors, which is proof that the stack scales down as gracefully as it scales up.
The trade is clear. You get full control and low licence cost, and in exchange you own data quality, uptime and every upgrade.
What a commercial IoT platform adds
A commercial platform wraps device provisioning, a rule engine, dashboards and alarms into one product. ThingsBoard is the canonical example: multi-protocol ingest over MQTT, HTTP, CoAP and LwM2M, a low-code rule engine, a ready-made air quality solution template with a computed AQI field and alarm rules, and separate public and administrative dashboards. Its edge deployment is a paid add-on, which tells you where the open-core line sits.
The trade is the mirror image. You get speed and support, and in exchange you take on a subscription and a degree of lock-in. Explore the ThingsBoard air quality monitoring use case to see the pattern.
Scale is a design input, not an afterthought
A network of 1,000 sensors reporting once a minute produces roughly 1.44 million readings a day. That’s not a spreadsheet. Plan for a time-series database or a streaming layer from day one, because retrofitting scale onto a prototype built on flat files is the most expensive rewrite in this chain.
Smart-City Interoperability: OGC SensorThings API and NGSI-LD
If your data must land in a municipal or national platform, the procurement usually names a standard. Hardware and data layers that already map to it win tenders; proprietary-only devices quietly get excluded.
OGC SensorThings API (STA) is the open standard for exposing IoT sensor timeseries over a web API. It’s built on the OGC and ISO observation models, and it complements ordinary IoT transports rather than replacing them. The Fraunhofer FROST-Server is the most widely deployed open-source implementation, available as a container and used with GIS tools through a QGIS plugin. Cities including Ferrara and Madrid run production air quality integrations on it, and the standard has been validated at the scale of hundreds of millions of records.
ETSI NGSI-LD, paired with FIWARE Smart Data Models, is the European context-data standard underpinning municipal data spaces. Its AirQualityObserved model (fields for id, dateObserved, location and the pollutant concentrations) is how cities harmonise sensors from different manufacturers. A typical FIWARE stack pairs the Orion Context Broker, an IoT Agent, QuantumLeap for timeseries, and Grafana for dashboards, with Keyrock and Wilma controlling API access. Santander, the cross-border Miskolc data space and the GreenMov cities all run variants of it.
What this means when you are buying hardware
You don’t need to implement either standard yourself. You need hardware whose controller exposes open protocols and whose gateway speaks MQTT, because that’s what lets an integrator map your data into STA or NGSI-LD.
Ask for the Modbus register map, the BACnet object list and the MQTT topic schema at procurement. A vendor who can’t supply them can’t integrate with a standards-based platform, no matter what the datasheet claims. The environmental monitoring station smart city deployment guide covers the wider architecture.
Public Air Quality APIs: What Each Is Good For, and the Traps
If you choose approach A, the comparison below is the shortlist worth evaluating. Coverage, licensing and cost vary enough that the wrong pick becomes a legal or financial problem later.
| API | Coverage | Auth | Freshness | Licensing and cost | Best use |
|---|---|---|---|---|---|
| OpenAQ | Global, ~100 countries | API key | ~30 minutes | Free | Cross-country consistency, research |
| US EPA AirNow / AQS | US plus Canada and Mexico | Key by email | Near real time | Free | Regulatory-grade US context, wildfire smoke |
| PurpleAir | 30,000+ sensors globally | Free developer key | Near real time | Free tier with points | Hyper-local density, with QA/QC flags |
| Google Air Quality API | 100+ countries, ~500 m | API key, billing | Hourly | Billed per request | Forecasts, heatmaps, 70+ local indexes |
| aqicn / WAQI | 11,000+ stations, ~1,000 cities | Token | Hourly | Free, attribution required | Rapid global lookup |
The licensing, rate-limit and freshness traps
Four questions decide whether a public API is production-viable. Can you redistribute or resell the data? Is attribution required? What is the rate limit, and what does your query volume cost per month? How fresh is the data, and which AQI standard and label does it carry?
The answers aren’t trivial. The aqicn/WAQI terms prohibit selling or redistributing the data and require attribution to the World Air Quality Index Project and the originating EPA.
Google’s Air Quality API bills per request, with volume pricing and a per-method queries-per-minute cap, so a busy map can generate a real invoice. Proxy your API keys through your own backend rather than the browser, cache aggressively, and always label the source, the update time and the AQI standard you’re displaying.
Data-quality flags travel with the data
PurpleAir’s low-cost sensors carry two laser channels, A and B, and report their agreement state: Validated, Channel Disagreement, Single Channel, Below Detection Limit or Saturation. A platform that plots those readings without inspecting the flag will confidently display a broken sensor.
Ingestion rules must drop or quarantine failing sensors, which is a data-quality discipline the platform shares with the sensors themselves.
How to Get Your Station Data Into a Platform: A 6-Step Checklist
If you own the stations, this checklist keeps the integration clean.
- Define the data contract. Agree which pollutants, which units, which sampling interval, and which quality-control and correction metadata travel with each reading.
- Confirm the device protocol. Identify whether the controller uses Modbus RTU/TCP, BACnet, M-Bus or an analogue signal, and obtain the register map or object list.
- Choose the uplink. Select LoRaWAN, NB-IoT or 4G, and settle the transport payload: MQTT JSON, HTTP or CoAP.
- Pick the platform approach. Consume, self-host, buy or expose, judged against ownership, interoperability and budget.
- Design storage and the API. Choose the time-series database, set retention and downsampling from raw to hourly to daily, then define the API surface or standard.
- Plan resilience and governance. Configure store-and-forward buffering and backfill, decide on-premise versus cloud for data sovereignty, and set API authentication and rate limits.
A station that measures air quality alongside temperature, humidity, wind speed, noise and particulate matter, and uplinks over NB-IoT or 4G, covers steps one through three by design. Black Ant’s environmental monitoring station carries that sensor set in an IP65 outdoor enclosure.
Its IoT Data Collection Terminal and Edge Data Acquisition Computer handle multi-protocol field input over RS485, M-Bus and 4–20 mA, support MQTT and NB-IoT or LoRaWAN uplinks, and process data on-site with OTA firmware updates. That’s what keeps the readings flowing to your platform when the cloud link drops. Request the station and gateway specification, or talk to an application engineer →
The Platform Is a Choice. Make It Deliberately.
Four things are worth carrying away. A platform and an API are different layers, and conflating them is where integration projects go wrong. The data chain runs from the station through a gateway, a broker and a time-series store to an API and a dashboard, and it fails at whichever stage nobody designed.
The four approaches, consume, self-host, buy or expose, are a choice rather than a default, and most real deployments blend them. Municipal work is increasingly won or lost on interoperability standards such as SensorThings and NGSI-LD. And licensing, rate limits and data-quality flags decide whether a build survives production.
The one constant is the data arriving at the bottom of the stack. Software can’t correct for a station that can’t buffer through an outage, or a gateway that can’t speak an open protocol. That’s why the hardware layer and the platform layer have to be chosen together, from the sensor module through the data terminal to the API that publishes the number.
If you are specifying outdoor stations for a city, an industrial site or a community network, our team can help you match the sensor set, the uplink and the protocol support to the platform you intend to run. Request the specification sheet and talk to an application engineer →
Frequently Asked Questions
What is the difference between an air quality data platform and an air quality API?
A platform ingests, stores, computes and visualises data from many stations. An API is the interface another system calls to read or write that data. A platform is a destination; an API is a door.
How does air quality sensor data get to a dashboard?
It moves through six stages: measurement, normalisation over Modbus or RS485, uplink over LoRaWAN, NB-IoT or 4G, an MQTT broker, a time-series store with quality control and AQI computation, then a REST or standard API that serves the dashboard.
What is the OGC SensorThings API used for?
It’s an open standard for exposing IoT sensor timeseries over a web API. Cities use it to give many systems read access to the same sensor data without custom integrations.
What is NGSI-LD in air quality monitoring?
NGSI-LD is the ETSI context-data standard, and FIWARE’s AirQualityObserved data model is how cities harmonise pollutant data from different manufacturers into a common format.
Which air quality API should I use: OpenAQ, AirNow, PurpleAir or Google?
It depends on coverage and constraints. OpenAQ for global consistency, AirNow for US regulatory-grade data, PurpleAir for hyper-local density with quality flags, and Google for forecasts and heatmaps at per-request cost.
Is there a free air quality API?
Yes. OpenAQ, AirNow, PurpleAir and aqicn/WAQI all offer free tiers, but each attaches conditions. Check redistribution rights, attribution requirements and rate limits before committing.
Can I build an air quality platform with open-source tools?
Yes. A broker such as Mosquitto or HiveMQ, Node-RED for flow logic, InfluxDB or TimescaleDB for storage and Grafana for dashboards is a proven pattern, provided you are prepared to own data quality and uptime.
How do I expose my own air quality station data as an API?
Start with a clear data contract, keep the controller on open protocols such as Modbus or BACnet, uplink over MQTT, store in a time-series database, and expose either a REST/JSON API or a standard such as SensorThings or NGSI-LD.
