Yep, it'd get my vote.   The built-in mechanism breaks down when volume increases, over the years I've tailored scripts to reduce rate various ways depending on what they were doing.   But what I'm seeing with some customers is use of apps that simply ignore rate limiting and just pound on the API service - for example, regular storms of 50,000+ calls with fewer than 500 succeeding, the rest are 429s. This has a knock-on impact on all the well-behaved apps.   IMO it'd also be good for the API service to detect apps doing this and simply block them for a period (perhaps increasing exponentially), rather than allowing them to exhaust the call budget and block out other apps. ... View more

I'm so used to people using the library that I didn't notice the OP was doing it the hard way. ... View more

You already posted a similar query https://community.meraki.com/t5/Developers-APIs/GET-networks-networkId-events-productType-appliance-amp/m-p/281786#M12897   If you look at my reply, you'll see that your usage...   "includedEventTypes[]": "non_meraki_vpn", ...is not correct.     ... View more

You might not be passing the array of strings correctly.   This code snippet is from one of my scripts, it works...   response = await aiomeraki.networks.getNetworkEvents(net['id'], productType="appliance", includedEventTypes = ["nbar_block", "cf_block", "sf_url_block", "sf_binary_block"], perPage=1000, total_pages="all")   ... View more

Possibly it relates to the data-link-id in the code of the Organization->Firmware Upgrade page.   You'd need to delve into the page code to see if/how you can turn it into a URL, bear in mind that sort of usage will be prone to breaking if Meraki change how the page works. ... View more

Happy birthday! 🍾 😀   ... View more

Leaving out error handling etc., the core elements to take a 'snapshot' of current status for all devices are in the code snippet below (I use aio in most of my scripts, and I've extracted this direct from one of those, but for this simple purpose you could rewrite without aio).   The availabilities endpoint doesn't return as rich a response, but if you also get the network and device details for the organization, you can then look up things like network names, device models etc.   async with meraki.aio.AsyncDashboardAPI( api_key=API_KEY, base_url='https://api.meraki.com/api/v1/', print_console=False, output_log=False, suppress_logging=True, wait_on_rate_limit=True, maximum_retries=10 ) as aiomeraki: # get the list of networks and devices so that you can look up extra info relating to the status responses networks = await aiomeraki.organizations.getOrganizationNetworks(ORG_ID, perPage=1000, total_pages="all") devices = await aiomeraki.organizations.getOrganizationDevices(ORG_ID, perPage=1000, total_pages="all") statuses = await aiomeraki.organizations.getOrganizationDevicesAvailabilities(ORG_ID, perPage=1000, total_pages="all")   ... View more

Be aware that the statuses endpoint is deprecated, it still works at the moment, but could be removed.   The availabilities endpoint is the replacement and will be the best to use.     Deprecation is explained here... https://developer.cisco.com/meraki/api-v1/deprecation/#deprecated-operations   ...and the statuses endpoint advisory is here... https://developer.cisco.com/meraki/api-v1/deprecated-operations/#2024-may   ... View more

See...   https://developer.cisco.com/meraki/api-v1/get-organization-devices-availabilities/     ... View more

As @John_on_API says - also explore the other endpoints in the 'alerts' category as they include ones to get the possible types (which could change over time.)   In spare moments I've been looking at these as a way of improving SLA/related reporting as it's richer info than the 'availability' endpoints.   ... View more

I WANT IT ... View more

General comment: it's called 'update', but the logic looks like...   prompt human for values - what if the human lies about the current port type? call the update endpoint   Whereas, IMO more logical would be...   call get endpoint to get current elements and values prompt human with current elements/values and option to change value call update endpoint ... View more

I've also seen occasional None values with this endpoint (going back years) - it can indicate inactive/removed devices/uplinks etc. - but as our use of it is only for monthly indicative reporting, I just drop those responses when they occur.   If you're seeing large amounts of None values that you know to be incorrect, i.e. uplink is known to be live, I suggest opening a case with Meraki support. ... View more

You can open a case with Meraki support to raise the issue.   Until resolved, the option is use the workaround. ... View more

The endpoint tells you the stage that failure occurred at and the type of failure. i.e. the failureStep and type elements. It's enough to know where things go wrong, for detail I'd look at the UI.     [ { "ssidNumber": 1, "vlan": 100, "clientMac": "22:33:44:55:66:77", "serial": "Q234-ABCD-5678", "failureStep": "dns", "type": "802.1X auth fail", "ts": "2018-02-11T00:00:00.090210Z" } ]     Looks like the Connection Log is also pulling data from network events... https://developer.cisco.com/meraki/api-v1/get-network-events/    If you want that info, you'll need to get the events and correlate the two, and maybe data from other endpoints as well.   The UI/API are two different views of underlying datasets, trying to replicate the UI view from the API can be complex or impossible, especially as neither the datasets nor the UI's algorithms and parameters are public. ... View more

No single endpoint will give all the details on the Connection Log page, like many things in the user interface, it is built from multiple datasets.   This one mentioned by @RaphaelL is the closest... https://developer.cisco.com/meraki/api-v1/get-network-wireless-failed-connections/   Given this, you can use other endpoints to recreate the details seen in the UI.   I.e. if you then want to know the client device name, you can relate the clientMac value to the list of clients on the network, which you can get from https://developer.cisco.com/meraki/api-v1/get-network-clients/   Same with the SSID name, you'll need to relate ssidNumber to the list of SSIDs for the network, which you get from another endpoint.   If you want to know which AP, you can do this by iterating over APs using the serial keyword argument rather than the default of all APs on the network. Of course you'll need first to get the list of AP serials for that network using another endpoint.         ... View more

I use https://developer.cisco.com/meraki/api-v1/get-network-appliance-security-events/ and iterate through the networks.   It's less efficient than the org-wide endpoint, but this way I know which network an event relates to.   It really would have been better if the org-wide call included the network details. ... View more

I think you already asked about this...   https://community.meraki.com/t5/Developers-APIs/Send-push-notifications-to-group-of-devices-via-API/td-p/268193/jump-to/first-unread-message   ... View more

As others have said, it's not really something the API does, it's really for your app developer to create a solution.   If you really wanted to use the API, you could use it to send a ping from a Meraki device to the target device IP, with a defined payload that a device could recognise as a command... https://developer.cisco.com/meraki/api-v1/create-device-live-tools-ping/   But it's not straightforward, you'd need to keep track of device ID:IP mapping and relate that to a Meraki device in the same local network, the device app will need to always be listening for a ping, and ping isn't reliable, also it's not secure as someone on the same network could also ping things, though you could harden it various ways.   ... View more

After hitting the problem, I gave up on the history endpoint as the priority was moving off the deprecated getOrganizationDevicesStatuses which has been having issues affecting our customer reporting.   Now I'm just polling https://developer.cisco.com/meraki/api-v1/get-organization-devices-availabilities/ it seems to be working correctly. Switched over to this the last week of February and next week we will be doing a full month cross-check against our independent service management platform to see if the two match.   ... View more

Except for the tiny values, I see all round numbers, the org I'm testing on is all MX18.x, I'll see if I've any with MX19 to try. ... View more

Thanks, that looks like a similar distribution.   I wonder what the expected %CPU is for an idle MX? The very low values returned for some devices do not seem likely.   Fwiw I checked an MX85 that the API is reporting < 0.00005% for yesterday, it's passing c. 20kbps traffic on average, it's not busy but I don't believe the CPU is below 0.00005%.   Maybe best to set quantity high, but throw away results less than, say, 0.5%. ... View more

If I loop through a single day, 18th February 0000 UTC, with a 1800 difference between t0 and t1, i.e. requesting 48 time slices in total, the endpoint only returns data for one time slice in each 4 hours.   Change the date to 19th March, and I get data for every 30 minute time slice.   Tested on the two orgs, exactly the same behaviour.   Is that expected behaviour?   It suggests that data older than some period is being discarded or consolidated into a few time buckets per day, if that's correct it would be good to have that period documented.     ... View more