Getting Device Details Using Dashboard API

[MaorSter]

1. Considering the following API, organizations/:organizationId/devices/statuses?serials[]=ABCD-1234-EFGH, I would like to know:

a. Is there a way to get a “leaner” response using query params (or using another method)? For instance, is it possible to get this minimal response: 

{

    "name": "switch-name",

    "serial": "ABCD-1234-EFGH",

    "mac": "11:22:33:44:55:66",

    "publicIp": "216.40.28.234",

    "networkId": "L_12345",

    "status": "online",

    "lastReportedAt": "2023-02-20T09:29:43.459000Z",

    "productType": "switch",

    "model": "MS250-48FP",

    "lanIp": "192.168.6.3",

    "gateway": "192.168.6.1"

}

2. What does the “serial” attribute mean in the context of switches and devices? Is it a GUID generated by the dashboard or is it deterministic for every device, i.e., when disconnected and reconnected to the system, will it receive the same serial ID?

3. What device models are supported by the dashboard? Only Cisco/Cisco Meraki models? If not, please direct me to a proper list.

[sungod]

1 - not sure what you are after

2 - the serial number is the physical device's unique serial number, it is also printed on the device's ID label.

3 - all Cisco Meraki devices are supported (except some obsoleted ones), that is the primary function of Dashboard. There is some limited support for some Cisco switches. The only non-Cisco devices supported are those covered by Systems Manager, smartphones, laptops etc.

[rhbirkelund · Accepted solution]

---

1. Considering the following API, organizations/:organizationId/devices/statuses?serials[]=ABCD-1234-EFGH, I would like to know:

a. Is there a way to get a “leaner” response using query params (or using another method)? For instance, is it possible to get this minimal response: 

{

    "name": "switch-name",

    "serial": "ABCD-1234-EFGH",

    "mac": "11:22:33:44:55:66",

    "publicIp": "216.40.28.234",

    "networkId": "L_12345",

    "status": "online",

    "lastReportedAt": "2023-02-20T09:29:43.459000Z",

    "productType": "switch",

    "model": "MS250-48FP",

    "lanIp": "192.168.6.3",

    "gateway": "192.168.6.1"

}

---

What do you mean by "leaner response"? Using the query params, you simply filter out all the device statuses according to what you're interested in. When using that endpoint to you get device status of all devices in your organization, which network they're added to, whether it's online, offline or dormant, LAN ip etc. The query params will simply filter devices in your REST query.

2. What does the “serial” attribute mean in the context of switches and devices? Is it a GUID generated by the dashboard or is it deterministic for every device, i.e., when disconnected and reconnected to the system, will it receive the same serial ID?

---

The serial attribute, is simply the device serial number. This does not change, and will always be the same. It is unique for all devices. The only examption could be the vMX.

---

3. What device models are supported by the dashboard? Only Cisco/Cisco Meraki models? If not, please direct me to a proper list.

---

Mainly Cisco Meraki devices are supported. There are a select few Cisco Classic devices which may be added to the Meraki Dashboard either in Managed or Monitored mode, but this is currently in a beta stage.

You may reference the Meraki Dashboard API here.

[MaorSter]

1. I'll try to clarify my intentions: when I query the devices, I tend to filter over the device type (let's say, switches) in my system, the full response model contains many attributes which are of no use to my solution, e.g., "tags", "components" and so on. As I intend to scale up the number of queried devices, I wish to reduce the size of the response in order to mitigate the traffic load on the network. Is this an option? Would you suggest a different approach?

[rhbirkelund]

Really, the traffic load is neglible, when querying the API. Especially that endpoint.

You could simply loop over the response, and then pop all entries where 'productType' != 'switch'

[sungod]

In this case, I would not worry about the response size. I have a script that uses this and other calls, in total it takes just a couple of seconds on an organization with >400 networks and thousands of devices.

It could be that adding extra filters might actually increase the load on the API service - extra processing is needed to check each item against the filter(s), rather than just sending 'everything'.