There's a chance the minimum timespan is not documented or enforced. A 30-minute minimum timespan seems reasonable for some aggregate stats. But yes, a support case would be needed to nail it down. ... View more

The dashboard API library has also been updated. ... View more

Hello @amattison ,   I cannot confirm this on my end, but what you've described here could be a bug. Please report it through Meraki support with steps to reproduce the issue.   Kindly, John ... View more

Just to clarify--the formatting of the URL did not change. It's always been a string. ... View more

Hi @ag_scilo, thanks for reaching out, and sorry to hear that your lab script has started having issues.   Have the URLs in the results for a paginated response been updated recently? as recent as last weekend( Jan07-2024) We are seeing returned URLs with "api.meraki.com" now, when we previously saw results like "n392.meraki.com"  or something similar. The contract around pagination URLs has not changed--pagination URLs should be treated as opaque strings as usual. Unless otherwise specified (e.g. as in a documented enum), the default assumption for any string value returned in API is that it should be treated opaquely.   In some cases, pagination URLs have included shard names (e.g. n392) but it's not reasonable to assume that this URL will follow a specific hostname format. Most pagination URLs will include something like api.meraki.com (or a hostname more relevant to your specific cluster), but again, that's not safe to assume in all cases, because these fields are not guaranteed to comply with a specific format beyond being a valid HTTPS URL for the purposes of pagination. If you have code that expects the hostname to include a string such as n392, then it will likely fail in any case where the pagination URLs do not include such a string.   I hope this helps, and let us know if you have any other questions. ... View more

Hi @xxia,   If you could, please open a support case for this. This doesn't seem right.   Kindly, John ... View more

@MartinS wrote: Fantastic, getAdministeredIdentitiesMe is exactly what I'm looking for, thanks very much @John_on_API !   Just as a side point, is there a best practice guide on how managed services organisations should use accounts and generate API keys when integrating with 3rd party systems like Highlight? I ask because generating API keys on user accounts associated with individuals is dangerous because if that individual leaves the MSP, their account gets suspended and that kills the key (we've seen this happen several times).    I'm guessing the right thing to do is have a key associated with a non-personal api@serviceprovider.com account where the credentials are carefully managed and not widely known, but where emails to api@serviceprovider.com do get delivered somewhere? I'd recommend that approach in most scenarios for now.   The email should be something that's clearly named and helps identify who manages the key/credentials, e.g. serviceaccount@partnerdomain.com. As the partner, you should not share these credentials (password or API key) with the customer.   Customers who want to revoke partner access would simply delete the given admin from their admins list. The customer would never have the API key for that identity. ... View more

Hi @PhilipDAth I suspect this was one of the issues solved recently: https://github.com/meraki/dashboard-api-python/issues?q=is%3Aissue+is%3Aclosed   ... View more

Searching the docs I can find a few that are related to packet counts (e.g. loss). https://developer.cisco.com/meraki/api-v1/search/packet%20loss/ ... View more

using the Meraki SDK   Hi @Brannen would you be able to link to the SDK that you are using? Based on your code, it looks like you might be using an obsolete SDK. It doesn't look like you're using the current Python library, which does handle rate limiting for you.   Also, check out this example local subnet dumper script. ... View more

Check out my post here ... View more

Try this API: https://developer.cisco.com/meraki/api-v1/get-organization-policies-assignments-by-client/   And use this query param: includeUndetectedClients ... View more

Hi @Prodrick, can you clarify what you mean by "connections"? I'm wondering if you mean this in the sense of "connection events" or "connected sessions" or perhaps something else. ... View more

This operation doesn't solve every problem (no operation does, ha!), but it should solve many.   Your top appliances by utilization are the most important ones to monitor, most of the time. Appliances trending towards 100% might be candidates for hardware upgrades. However, if an appliance isn't in the top 10 by utilization for that interval, then it means the other appliances in the organization all have average utilization lower than the least utilized appliance in the response. If your least utilized appliance is normally pretty low (e.g. under 50%) then it's pretty unlikely that hardware utilization is going to be a concern for any of the other sites.   But you don't need to take my word for it! The endpoint supports t0 & t1 controls so you can slice the data (e.g. 1 day at a time) and build your own graphs. You can use those stats to establish a performance baseline (e.g. a typical utilization percentage) for those top 10.   If you measure this over periods of time where you have known real-world usage spikes, then that will yield you some stats about how usage spikes can impact the appliance utilization. For example, imagine that the norm for a given office is 50% appliance utilization, but you've measured that a big team on-site event caused the utilization to spike to 75%. It'd be reasonable to predict that subsequent onsite events for that office on that hardware could trigger a utilization increase of about 25 percentage points.   Generally, 75% isn't high enough to be concerning in most scenarios, especially if it's a temporary spike. On the other hand, if your "normal" utilization for that office creeps up to 75%, then you might predict that an onsite event could push the utilization (for that site and that hardware) to 100%. Then, that might be an actionable problem and/or a sign that it's time to upgrade the MX hardware at that location.   Separately, if you correlate these stats with real-world user experience data (e.g. support cases for "slow Internet" or "slow VPN") then you can build some personalized metrics about which utilization percentages might be of concern to your users for specific models. For example, if users at a site are suddenly opening lots of support tickets about slow WAN/VPN etc., and you see that the utilization is 95%, then there might be a hardware bottleneck.   All of this is to say that, if your top 10 by utilization are typically pretty low, then additional datapoints about the other appliances are probably not much of a concern. And separately, if your top 10 are usually pretty high, then you probably have enough data already to start addressing potential hardware bottlenecks that might be causing user experience issues. ... View more

Glad it hear it! Thanks for the confirmation. ... View more

Dashboard API Python Library v1.39.0 published!🐍✌🏼1️⃣⏺️3️⃣9️⃣⏺️0️⃣   Library version 1.39.0 includes the latest capabilities released in the latest dashboard API release.   Install or upgrade with:   pip install --upgrade meraki   ... View more

Sure, although the example is correct. If you are having an issue using it with your organization, please do open a support case.   GET https://api.meraki.com/api/v1/organizations/:organizationId/wireless/devices/channelUtilization/byDevice   [ { "serial": "actual AP serial", "mac": "actual AP MAC", "byBand": [], "network": { "id": "actual network ID" } }, { "serial": "actual AP serial", "mac": "actual AP MAC", "network": { "id": "actual network ID" }, "byBand": [ { "band": "2.4", "wifi": { "percentage": 18.48 }, "nonWifi": { "percentage": 1.55 }, "total": { "percentage": 20.03 } }, { "band": "5", "wifi": { "percentage": 1.82 }, "nonWifi": { "percentage": 0.19 }, "total": { "percentage": 2.01 } } ] }, { "serial": "actual AP serial", "mac": "actual AP MAC", "network": { "id": "actual network ID" }, "byBand": [ { "band": "2.4", "wifi": { "percentage": 40.78 }, "nonWifi": { "percentage": 2.56 }, "total": { "percentage": 43.34 } }, { "band": "5", "wifi": { "percentage": 14.83 }, "nonWifi": { "percentage": 0.52 }, "total": { "percentage": 15.35 } }, { "band": "6", "wifi": { "percentage": 0.41 }, "nonWifi": { "percentage": 0.12 }, "total": { "percentage": 0.53 } } ] }, { "serial": "actual AP serial", "mac": "actual AP MAC", "network": { "id": "actual network ID" }, "byBand": [ { "band": "2.4", "wifi": { "percentage": 20.63 }, "nonWifi": { "percentage": 7.13 }, "total": { "percentage": 27.76 } }, { "band": "5", "wifi": { "percentage": 13.01 }, "nonWifi": { "percentage": 0.77 }, "total": { "percentage": 13.78 } }, { "band": "6", "wifi": { "percentage": 0.22 }, "nonWifi": { "percentage": 0.05 }, "total": { "percentage": 0.27 } } ] }, { "serial": "actual AP serial", "mac": "actual AP MAC", "network": { "id": "actual network ID" }, "byBand": [ { "band": "2.4", "wifi": { "percentage": 41.99 }, "nonWifi": { "percentage": 6.26 }, "total": { "percentage": 48.25 } }, { "band": "5", "wifi": { "percentage": 2.79 }, "nonWifi": { "percentage": 0.11 }, "total": { "percentage": 2.9 } } ] } ]     ... View more

Please feel free to open a support case on this. What you've described does not sound like expected behavior. ... View more

Hi @JGill, I recommend opening this as an MX feature request through your sales rep. ... View more

You can find the assigned switchProfileId via: https://developer.cisco.com/meraki/api-v1/get-network-devices/   You can update it via: https://developer.cisco.com/meraki/api-v1/update-device/   ... View more