Read more about Dashboard API Version 1.23.0
Via our What’s New Page here
Summary of Changes
*6 - New
*125 - Updated
*551 - Total Endpoints
*348 - Total Paths
What's New?
Do you ever wonder who you are when developing an application? Now you can easily get the name, email and other details of the account bound to the API key currently in use.
[API Docs]((https://developer.cisco.com/meraki/api-v1/#!get-administered-identities-me))
*Early API Access*
Added
"x-release-stage": "beta" to all beta operations and properties that are available for Early API Access users.
This is available in the v1 beta branch of the Meraki OpenAPI specification. Documentation, SDKs and other tooling can now take advantage of this information to highlight features that are in development.
*API Response Schemas*
We are excited to begin including API response schemas in the OpenAPI specification and documentation. In addition, over 1/3 of all existing endpoints have recently been updated to include schemas with more to come.
*Webhooks*
With the launch of webhook integrations, there have been a number of new solutions that have been made possible such as IT notification bots, provisioning workflows and custom security requirements for inbound API calls.
We are also happy to announce two new integrations, that were contributed by our community, for all to use as custom payload templates!
**Visit our Changelog today to read about all the latest updates!**
You guys are really cranking it!
Very good to see response schemas added!
First thing I looked at was getOrganizationSensorReadingsHistory as I'm working on some analysis/reporting of sensor data.
But the schema and example data shown on the do not match the call's behaviour.
Is the call behaviour going to change to match the schema? Or is the example schema and data incorrect?
At the moment the real response format seems inconsistent with sensor type, it would be good if all sensors would change to conform with what the schema/example show.
Schema/example data shows multiple metrics (having the same timestamp) returned. Whereas the actual return for an MT10 returns two separate readings, and for the sample data I've seen posted for MT14, that sensor returns an array of readings.
#MT10 two separate readings are returned, each with a single metric, whereas schema and example show multiple metrics returned in a single reading
#same device, same timestamp, returned as two separate readings
{'serial': '1234-5678-9012', 'network': {'id': 'L_1234567890', 'name': 'some name'}, 'ts': '2022-07-07T23:57:53Z', 'metric': 'humidity', 'humidity': {'relativePercentage': 60}}
{'serial': '1234-5678-9012', 'network': {'id': 'L_1234567890', 'name': 'some name'}, 'ts': '2022-07-07T23:57:53Z', 'metric': 'temperature', 'temperature': {'fahrenheit': 68.1, 'celsius': 20.06}}
#MT14 data reading contains an array of metric readings, each with its own timestamp, again not matching the schema/example (sample below is from this post... https://community.meraki.com/t5/Developers-APIs/Need-MT14-example-response/m-p/153771/highlight/true#M6210 )
#| haven't got an MT14 in the lab to test, but I assume this data that was posted is correct
"serial": "xxxx-xxxx-xxxx",
"network": {
"id": "networkID",
"name": ".core"
},
"readings": [
{
"ts": "2022-07-03T15:41:56Z",
"metric": "pm25",
"pm25": {
"concentration": 3
}
},
{
"ts": "2022-07-03T15:41:55Z",
"metric": "tvoc",
"tvoc": {
"concentration": 4310
}
},
{
"ts": "2022-07-03T15:41:46Z",
"metric": "humidity",
"humidity": {
"relativePercentage": 48
}
},
{
"ts": "2022-07-03T15:41:36Z",
"metric": "temperature",
"temperature": {
"fahrenheit": 76.6,
"celsius": 24.78
}
},
{
"ts": "2022-07-03T15:41:36Z",
"metric": "noise",
"noise": {
"ambient": {
"level": 33
}
}
},
{
"ts": "2022-07-03T15:41:30Z",
"metric": "indoorAirQuality",
"indoorAirQuality": {
"score": 82
}
},
{
"ts": "2022-05-07T22:44:46Z",
"metric": "battery",
"battery": {
"percentage": 100
Hi @sungod great question!
I can confirm that the endpoint is working as expected (one item in the index per metric per timestamp); however, the example and schema are a bit tricky since the 'metric' attribute informs which metric is included in a single array item.
We're looking into how we can be more explicit in the spec.
Thanks for clarifying.