Platform
API & Developer
Everything the interface does is available over HTTP. The API is the same one the platform itself runs on, so there is no second-class path for developers.
What is available
- Search — full-text and typo-tolerant, with filters for network, country and measurement.
- Geographic query — everything within a radius of a point.
- Sensor detail — metadata and the latest reading for a single sensor.
- History — readings for a sensor across the 1h / 24h / 7d / 30d / 1y windows.
- Facets — distributions by network, country, category and measurement, for building filters.
Shape of the data
Responses are JSON. A history response is a series of [timestamp, value] pairs keyed by measurement, with an explicit source marker — so a consumer can verify it is handling measured data and not something derived.
Working with sensor data
Three things trip up almost every integration, and they are worth stating before you hit them.
- A last value is not a current value. Every sensor has a most-recent reading; some are minutes old and some are years old. Always read the timestamp, and treat staleness as a first-class property.
- Counts and states do not mix. Occupancy feeds in particular publish incompatible quantities — a binary bay state, a count of free spaces, and a count of occupied spaces. Normalise before aggregating.
- Absence is information. A sensor with no history has usually never reported, which is different from a sensor whose feed just went quiet. Both matter; they are not the same.
Access, rate limits and terms are covered on the Pricing page. Use of the API is subject to the Terms of Service.