Hello,
I was looking at the dashboard RESTful API looking for ways to automate data extraction from devices and networks from the dashboard, but I noticed a lot of information that can be found on the HTTP version of the dashboard cannot be retrieved through the API. Examples:
IP configuration details of devices (gateways, DNS, vlans, etc); syslog settings, among other configuration details.
Are those information still missing in the API or it is just a documentation issue? Are there plans for newer and more complete releases of the API?
Thank you.
I have tried to do what you have mentioned - but I think the API is more designed around provisioning devices rather than extracting information.
I doubt that.. many extraction functions, but incomplete information. Considering Meraki is a web based environment you cant even connect to the devices to download its configuration file (that might be needed for many different enterprise processes, such as security compliance health checks for instance), a complete API is a must.
Agreed! Large Enterprise customers need a full API to effectively manage these devices in this day and age. I've actually written quite a lot of modules to use the API, but found it was missing key information I needed, such as editing the notes field on devices (among other things). The thing about a great API is how many possibilities you open up to advanced customers to solve problems.
Can you share with me the types of modules you've written and what limitations you encountered? I've written a number of sample API projects for Meraki and would like to get more perspective from real users.
Thanks
Cory
I want to utilise the API for our company but we need the App Version in the API before I can even recommend a project.
Thank you,
Peter James
What is the "App Version"? Are you referring to applications that are sent to mobile devices via Systems Manager? The APIs for this product focus primarily on the devices to automate provisioning. The capabilities are expanding, so I'm interested what the end goal might look like.
@DexterLaBora Yes. The installed applications on a client device, alongside their installed version number.
I would like to query the API for a device and its installed Applications and version. You have a field (missingAppsCount) that shows how many applications are missing from the device, so this information you must clearly have already.
You currently have "https://dashboard.meraki.com/api/v0/networks/[networkId]/sm/devices"
Which offers the following:
"Additional fields that will be displayed for each device. Multiple fields can be passed in as comma separated values. The default fields are: id, name, tags, ssid, wifiMac, osName, systemModel, uuid, and serialNumber. The additional fields are: ip, systemType, availableDeviceCapacity, kioskAppName, biosVersion, lastConnected, missingAppsCount, userSuppliedAddress, location, lastUser, publicIp, phoneNumber, diskInfoJson, deviceCapacity, isManaged, hadMdm, isSupervised, meid, imei, iccid, simCarrierNetwork, cellularDataUsed, isHotspotEnabled, createdAt, batteryEstCharge, quarantined, avName, avRunning, asName, fwName, isRooted, loginRequired, screenLockEnabled, screenLockDelay, autoLoginDisabled, hasMdm, hasDesktopAgent, diskEncryptionEnabled, hardwareEncryptionCaps, and passCodeLock."
We just need two new fields: installedApps and installedAppsVers.
Hi there
I think some of the missing API is.
When creating a new network, it is not possible to clone a existing network.
There are no API calls that can tell if a switch/firewall is online.
Mvh M
@DexterLaBora It might be a good idea to link this page : https://documentation.meraki.com/zGeneral_Administration/Other_Topics/The_Cisco_Meraki_Dashboard_API to the community board.
Hi -
We are working with this API using a CURL command.
"https://dashboard.meraki.com/api/v0/networks/[networkId]/sm/devices"
We are successfully getting the device default data, but in this portion of your post shown below you mention 'additional fields'. We want to pull the phone number and IMEI. Possible?
Multiple fields can be passed in as comma separated values. The default fields are: id, name, tags, ssid, wifiMac, osName, systemModel, uuid, and serialNumber. The additional fields are: ip, systemType, availableDeviceCapacity, kioskAppName, biosVersion, lastConnected, missingAppsCount, userSuppliedAddress, location, lastUser, publicIp, phoneNumber,
Belay that last inquiry,
I was able to extract the added fields using this syntax:
https://api.meraki.com/api/v0/networks/N_57758665221026xxxxx/sm/devices?fields={phoneNumber},{imei}
Cory,
I would love to share some of the limitations of the API with you in a large Meraki implementation. Since Meraki has not built a security model to delegate administrative features customers have to look to building their own Administration Dashboard, but with the current API limitations this isn't even possible, or should I say worth the time for the functionality (result).
-Andy
I haven't looked into those particular features, but I have found that most (all?) of the Dashboard is REST/JSON based, so you can probably hack something up with a bit of reverse engineering.
Hi Forster,
Looks like we need to update the documentation page here. Several of the example configuration details you mentioned are available but not shown on the API docs page. Your examples like Subnet, DNS settings (some), and Add/Remove VLANs are available in the VLANs endpoint of the Dashboard API. Configuring Syslog servers is however not available.
GET /networks/[networkId]/vlans API Docs page
How would anyone know about the API endpoints if they are not on the API docs page? Our documentation page is only the very tip of the iceberg. Have you visited the Meraki Developers website? Here are some helpful links:
http://developers.meraki.com/api - Dashboard API
http://developers.meraki.com/postman - Postman collection
https://github.com/meraki/ - Open source code
There is an entire python library of sample code on our GitHub to help get you started. Also, an easy way is to configure it on the dashboard, and then do a GET request via API to see the syntax.
The Dashboard API launched less than 2 years ago, and we've invested a great deal of engineering effort on growing not just it's comprehensiveness/completeness, but also we've improved its responsiveness. The API is version 0 today, and new features are being added all the time.
Thanks,
Colin Lowenberg
Updating my answer above. The parameters you were looking for are now visible in the API Docs here: https://dashboard.meraki.com/api_docs#update-a-vlan
The API Docs shows this example request:
[
{
"id": 1,
"networkId": "L_646829496481095588",
"name": "Default",
"applianceIp": "192.168.128.1",
"subnet": "192.168.128.0/24",
"fixedIpAssignments":
{
"b8:f6:b1:17:2c:b3":
{
"ip": "192.168.128.10",
"name": "Forster"
}
},
"reservedIpRanges": [
{
"start": "192.168.128.5",
"end": "192.168.128.9",
"comment": "Hello world"
}
],
"dnsNameservers": "google_dns"
}
]
It's a very big problem. Some of us ISP users have to scrape pages, fill out forms like a hacker, and try to get things done because the API is seriously lacking. Also this is not at all fast. It can take hours to configure a few hundred boxes. I'm not at all impressed by Cisco.
If you mean initial configuration after boot, yes. The API allows us to do that. But usually we know some information only after the box is online. Like secondary public IP's, additional VLANs, the customer has new firewall rule needs every so often. And we need updates to various objects at different points in time.
We want things like creating and enabling a port with a new VLAN to route public (!) traffic over. Synchronizing some new firewall rules across all devices of several tenants. A more complete API or docs would be tremendously helpful.
It turns out that there is a direct contact with Meraki that knows our situation. So together we'll work towards a better situation.
Hello,
As stated in one of my other posts we are trying to get data out of the Meraki Dashboard to feed into other systems eg: CMDB and initialy thought the inventory call -
/api/v0/organizations/648916/inventory
-
"mac": "00:18:0a:0b:80c:0d",
"serial": "QQQQ-UUUU-1111",
"networkId": "A_123456789",
"model": "MX100",
"claimedAt": "1496173973.76468",
"publicIp": "10.12.18.5"
Would provide the same of more than what was on the Organization inventory Page ( but per Network )
but:
- no name
- IP is NAT IP not Device IP
- Network ID not name ( not a big deal )
- No Country/Region
It would make sense that if there is a concensus that "We need to see X in the GUI" we will want the same data available via an API call ?
Thanks,
Don
PS: The trap content needs some massaging as well 🙂
How about adding in more API options for switching, to be able to add routes, VLANs and ACLs? Is there a specific limitation to the API, or is it just the calls you are allowing?
I'm a bit surprised at how much is missing from the API compared to what can be done via the Web UI. One thing that really disappointed me was discovering, today, that there's a rate limit on the API calls (5 per second per organization) and that it apparently cannot be tuned. That was like a kick to the gut. That's not going to scale very well. We have thousands of network containers and polling that information in serial fashion takes way too long. I was already working on scripting that would run dozens of threads concurrently but that's way down the priority list now. One thing that would be really nice to see is a object returned by the Networks pull that includes a time/date stamp for the last time any configurable attribute of the parent container or any child container (such as a device) changed. 99% of my iteration work would disappear immediately (unless somebody made bulk changes).
If you are monitoring for changes to the configuration, this data is available as an Email or SNMP Trap today, and you can configure this under Network-wide > Alerts.
If you are monitoring for device status try this API endpoint:
Thanks!
Hi,
One significant issue we have with the traps is the content, ( or lack there of) every trap needs to have a target !
Most have MAC which is not helpful when trying to associate the Alarm to a CI in the CMDB against which you are trying to assert that Alarm, the trap must supply Hostname / IP Address to be useful.
thanks,
Don
@JHO We have not implemented the API for ACLs and L3 routing on switches, so it's a feature that needs to be built.
The VLAN configuration is available in the API today - it's under the SwitchPort endpoints:
This call was better, but I still need to make a second call to get device type Z3 Etc...
We are also trying to determine which devices are Really in Production Vs. have been staged then shut off until True deployment.
The status is useful, but I am thinking that is as of N minutes... Eg. it’s up now but for how long.
Is is there any way to know a device is Production other than online and Passing traffic ?
thanks,
Don