1 I suggest https://developer.cisco.com/meraki/api-v1/get-organization-wireless-ssids-statuses-by-device/ 2 there are many different calls to update different things 3 on an existing device you can use https://developer.cisco.com/meraki/api-v1/get-device/ to get the current settings, for a new device you need to create the settings yourself I strongly recommend read through the complete API guide, starting at https://developer.cisco.com/meraki/api-v1/introduction/   Then at least review all the API calls to get an idea of what is there, also you can use the search to find calls containing a keyword you are interested in, like SSID for instance... https://developer.cisco.com/meraki/api-v1/search/?q=ssid As you will be using the Python library, I would begin making some scripts to gather/format the data you are interested in, to get a feel for how things work.   ... View more

You need to call by ID not name. ... View more

There is only one co-term date in an org using co-term licensing. Use https://developer.cisco.com/meraki/api-v1/get-organization-licenses-overview/ There is no such thing as "device level co-term license information with claimed and expiration date". Co-term is org-wide, all licences/devices in the org have the same co-term date. For instance, our lab network has 27 licenses covering many different devices types, with a mix of license durations, all claimed at different times, but they all go into the co-term pot and there's only one co-term date for all of them. ... View more

No, that's not how co-term works. Across all the licenses in the org, you must have enough licenses to cover the total number of devices. If you had, say, 1,000 devices, you could have one licence for 1,000, or two for 500, or ten for 100, or one 500 plus two 200 plus one 100, doesn't matter, as long as the total is >= the number of devices, they will all have the same co-term date. You cannot 'split' 100 device licenses into 150 device licences with a reduced co-term date. From what you are saying  I'm guessing you are talking about System Manager licenses. I recommend reading the link posted by @DarrenOC and also this below which explains the difference between adding/renewing behaviour... https://documentation.meraki.com/General_Administration/Licensing/Meraki_Licensing_-_License_More_Devices_vs_Renewal   ... View more

1 yes and yes, btw make sure to add the new licence to increase number of devices, not to extend the term of the existing 50 2 you can have an arbitrary number of co-term licences in an org, there are a few endpoints for licensing, you can search the API documentation to find all that have the word... https://developer.cisco.com/meraki/api-v1/search/?q=license for instance... https://developer.cisco.com/meraki/api-v1/get-organization-licenses/ https://developer.cisco.com/meraki/api-v1/get-organization-licensing-coterm-licenses/   ... View more

You need to use the pagination features, see... https://developer.cisco.com/meraki/api-v1/pagination/ A simple way is to use the Meraki Python library as it can handle this for you, as well as rate limiting, which is another topic... https://github.com/meraki/dashboard-api-python https://developer.cisco.com/meraki/api-v1/rate-limit/ ... View more

I'd just assume it's a transient failure, API endpoints are not 100% reliable/available. You can always open a support case, always do this if a problem persists.   ... View more

The response has an array of individual peers, an individual peer can only be either reachable or unreachable. IMO the Dashboard "Some peers are unreachable" simply means there are least two peers with at least one peer in each state, i.e. it's a 'calculated state' from the list of individual peer states. ... View more

In general, AP states match those in Dashboard documentation for the device/function, as a first step that's where I'd look/search. See https://documentation.meraki.com/MX/Site-to-site_VPN/VPN_Status_Page and you'll find it matches what @pdeleuw says. ... View more

Not specific to the location API, it's common for people to report API data not matching what is visible in Dashboard.   The answer in general is that unless you are exactly replicating Dashboard's internal logic/timing/maths, the result will differ, and as the internal details are not public it's unlikely you'll be able to replicate them, so you'll always get different numbers.   For instance I'm pretty sure Dashboard keeps some periodically calculated/cached info for some things, unless you can hit on the exact match for this, you won't get the same results.   They're not wrong, they're just different because they weren't calculated the same way that Dashboard does it, as long as you know what they mean they are perfectly valid.   There is some explanation of how the numbers for Location Analytics are produced, it might help you get closer, note how RSSI is used for instance... https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics   But if you are using the API, totals still have to be calculated, otherwise I think you'll have to resort to extracting the numbers from the Dashboard page.   The API documentation says you get clientMac in the payload... https://developer.cisco.com/meraki/scanning-api/3-0/#observation-payloads ...if that's not what you're getting, I suggest open a case to get it fixed or documentation corrected. ... View more

Quite a few endpoints have no schema definition, perhaps as in some cases it would vary depending on the response data/device config.   If you look at the 'Example Body' tab, what you see is effectively the definition, you need to work from that.   Code defensively...   Interpret any element that is an array as potentially containing 0 or more elements .   Do this even if you believe it must have at least 1, like the uplinks array for instance, but watch out! If the device was added to a network, but has not connected so far, I'd suspect that uplinks may have 0 elements.   Assume that any element that is an empty array may or may not be included in the response, code to handle both possibilities.   ... View more

If you want only counts of wireless clients in a given period, you can use... https://developer.cisco.com/meraki/api-v1/get-network-wireless-client-count-history/   But if you want to get/calculate the same info as the location analytics page there're a few ways I can think of... use the API @alemabrahao mentions and accept the volume of data, plus keep a database of clients so you can do the calculations over time if you want the 'Connected' number, you probably also have to correlate with actual connection data for matching time span from https://developer.cisco.com/meraki/api-v1/get-network-wireless-clients-connection-stats/ ...or... examine the way the CSV links on the location analytics page operate, emulate that in a script to periodically get the data as CSV, though I'd bet this is easier said than done. ...or... create a screen scraper to pull the numbers from the page. ... View more

The documentation, examples and Liquid templates certainly imply that it is one device alert per-webhook. It's what I've always assumed.   None of the sample alerts has the device details the alert refers to represented as an array element, without that kind of structure I don't see how multiple devices could be packaged in the payload and still match the template. ... View more

I think this has come up before, but afaik there's nothing in the API to get this info.   Seems like one to 'make a wish' for, how about figuring out exactly what you'd like to see as response data, and post in API Early Access Group as a proposal for a new/updated endpoint.   ... View more

If you insert an print to show the value of Test_id before the get, is it showing the expected org ID ?   I ask, because this code...       Test_id = 0     print(Test_id)     for org in orgs:         print(f"ID: {org['id']:<6} Name: {org['name']}")         if "Test" in org ["name"]:             Test_id = org["id"]   ...will leave Test_id = 0 if the condition is never true, giving the 404 error. ... View more

Yes, I'd rather see a gap than interpolation.   You can use the "Give your feedback" button at the lower right of the dashboard page to make the suggestion (used to be "Make a wish"), it may have better visibility.   ... View more

It's mostly from adapting from another script I wrote, the basics of set-up, iterating by something, error handling etc. are common across scripts, so whenever I do something new I tend to see which old script I have that is closest in structure to what I need and then adapt it, and I'm lazy 😀   This one is using async I/O as it is generally more efficient, but it does affect readability.   If you look on the github site, there are a few examples you can use as starting points to experiment...   https://github.com/meraki/dashboard-api-python/tree/main/examples   ... View more

The 'best' way to do it will depend on exact details/context.   I suggest look at switch templates and port profiles to see if using them would solve all/part of what you want to do...   https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MS_Switching/Templates_for_Switching_Best_Practices   https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Switch_Port_Profiles   The API can also be used with these.   Within the API, action batches a possible way to be more efficient when making a lot of changes...   https://developer.cisco.com/meraki/api-v1/action-batches-overview/   ... View more

Ah, I must be going blind, I missed that when I looked at the code!   A 1 second retry on 5xx responses seems hopeful at best 😀   ... View more

The main Meraki Python library retry mechanism is explicitly for handling the 429 response used by the API to signal the rate limit has been hit (there're also some other retry mechanisms for a few specific 4xx error contexts).   Your example shows a 502 bad gateway response, there will be no retry, it is a hard error.   If you want to retry on 502, you'll need to add your own code to do that, but as 502 errors may last a while I would recommend a fairly long interval before trying again.   ... View more

Pretty much what @RaphaelL says.   The details depend on what will be running this, for instance in a unix/linux environment if your script to go and grab the current port-AP list writes to a text file p-ap-tmp and if the 'database' is the text file p-ap-master, both files same format, one switch-port-ap record per line, both sorted. It can be done more compactly, but this way is clearer to see...   your_lldpcdp_script |sort >p-ap-tmp cat p-ap-tmp p-ap-master |sort -u >p-ap-new mv p-ap-new p-ap-master   Will keep p-ap-master updated with any additions, without losing records for APs that are no longer detected.   You could extend the shellscript to spit out a list of records for any missing APs...   comm -3 p-ap-master p-ap-tmp >p-ap-missing ... View more

Others have reported digging into Dashboard pages to use undocumented methods of accessing things. As long as you do not abuse it by driving a lot of activity I do not think there would be a problem.   The main issue is that if you use this technique, it can break at any time if Meraki make a change to the page or the behaviour of undocumented links.   ... View more