Partners

More than one sensor

Schools, councils, community air quality groups, housing associations, and the people who make the hardware. If you run a fleet, this page is the one that matters — /contribute is written for someone with a sensor on a windowsill.

Schools and universities

A sensor per building turns a science lesson into a dataset the students actually own. Classroom CO₂ is the most immediately convincing air quality measurement there is — it moves visibly when a window opens.

Councils and public bodies

Official monitoring is sparse because reference stations are expensive. A community network does not replace them and should not pretend to, but it does fill in the geography between them and shows where a reference station would be worth putting.

Community groups

A street, an estate, a valley. Twenty cheap sensors in the right places answer questions that one expensive one cannot — and the data belongs to the people who collected it.

Hardware makers

Ship openaqi support and your customers' devices contribute by default, with their consent. Their data is not locked in your cloud, and you get a public map showing your hardware in the field.

What we do with your data

The same thing we do with everyone's, which is the point. There is no partner tier of the privacy model.

Coordinates stay in one table
Used once to derive a ~5 km cell, never returned by any endpoint, and absent from the readings table entirely. That applies to a fleet of two hundred exactly as it applies to one.
Everything published is public
Cell-level aggregates, under the terms on our disclaimer page. If your data cannot be public, this is the wrong project and we would rather tell you now.
You keep yours
You can export everything you sent, and ask us to delete it. Contributing here is not exclusive and never becomes so.
Attribution both ways
Your organisation is credited on the cells it contributes to, if you want that. Some do; a housing association may prefer not to be identifiable, and that is fine too.

Running a fleet

One account, many stations, one key per station. Nothing about the mechanism changes at scale — it is the same registration and the same agent, scripted.

while IFS=, read -r name lat lon; do
  curl -s -X POST https://openaqi.net/api/stations \
    -H "Cookie: $SESSION" -H "Content-Type: application/json" \
    -d "{\"name\":\"$name\",\"lat\":$lat,\"lon\":$lon}" \
  | jq -r '"\(.station.id),\(.apiKey)"' >> keys.csv
done < stations.csv

Each line gives you a station id and its key, once. Keys are stored hashed, so that CSV is the only copy — treat it accordingly.

For a hundred sensors or more, talk to us first. Not for permission — for a higher tier, and so a sudden hundredfold jump in one area does not look like an attack to whoever is on call.

Tier	API reads/min	API reads/day	How
Free	60	10,000	Sign up
Partner	300	200,000	Ask — it is free too

Sending readings is not rate limited by tier. Only reading the API is, and that limit exists to stop one client accidentally scanning the planet, not to create a paid tier.

Siting, honestly

The most common way a well-funded network produces bad data is by putting every sensor where the cabling was easy. Some practical notes from the literature and from watching our own:

Outdoor sensors: 2–4 m up, away from walls that trap air, out of direct exhaust. A sensor above a car park measures the car park.
Indoor sensors: breathing height, not on top of a bookshelf, and not next to a kettle, printer or extractor.
Low-cost particulate sensors read high in fog and high humidity. That is the sensor, not the air, and it is worth knowing before someone raises an alarm about a foggy morning.
Electrochemical gas sensors drift and need replacing on a schedule — typically 1–2 years. A drifted sensor still produces confident numbers, which is what makes it worse than a dead one.
Co-locate one of your sensors with a reference station if there is one nearby. It costs one sensor and tells you how much your fleet can be trusted.

Talk to us

There is no form and no sales process. Open an issue, or email the address in the repository, and say what you have and what you want to do with it.

Useful things to include:

· roughly how many sensors, what hardware, and where
· whether you want your organisation named on the map
· anything about your obligations that we should know before you start

Open an issue Just one sensor? Start here