Hi @Robb1963 & @Dave2000    since these posts there have been more group policy endpoints added in the latest version of the API (v1).   Check out the endpoints here: https://developer.cisco.com/meraki/api-v1/#!get-network-group-policies   If you are copying from one network to another, it would be a simple case of 2 calls (assuming you know the grouppolicy id/network id/etc.): 1) get all network group policies. 2) create the new group policy in the new network based on one (or more) of the group policies from step 1.   Copying all group policies would just be a case of adding a loop in there so you would complete step one, then loop through ever GP and create a new one on each iteration.   Cheers, John ... View more

Hi @divman123    Some great questions around the move to v1.   Let me do my best at answering them...   All endpoints should exist somewhere in v1 (they will have been moved/amalgamated/etc., but should still exist). The endpoint you are looking for is: {{baseUrl}}/networks/:networkId/sm/devices/  I had a look in the documentation, and it might be slightly confusing, so I messaged the product managers to check out. I don't think there's going to be any additional information for what's been moved. The documentation site has a really good search feature to find what you need to. Have a search here, and you should find everything you need. We don't have an official v0 sunset deadline yet. For the last few months and going forward, there have been no new endpoints added to v0 - only v1 will receive feature updates. In terms of support, only broken fixes will be updated in to v0 (for example, documentation updates, etc. that are not affecting the endpoint itself will probably not be updated going forward, whereas something returning a 404, where it shouldn't be for example, would be fixed). After approx. 1 year we are going to look at the usage of v0 and actively reach out to developers who are still using the old version in an effort to help them move to v1. It will be at this point that the product managers are going to decide on a sunset timeline. That being said, I would definitely not be developing anything on v0 now (if it was me), so I would encourage everyone to move to v1 where all the shiny new features are, as well as a longer life of the version, etc.   Thanks! 😄  EDIT:    I've just had a message from the product managers that the SM endpoint I mentioned may not be available in GA (just beta testers) and this was because there was a minor issue that needed some work regarding the tags field on the SM devices (changing it to an array of strings, instead of one long comma-seperated string). We didn't want to release v1 officially and then alter the field type later (as this would be a breaking change), and we didn't want to hold up the release, so we just temporarily kept this one back. This is a high priority for the team and you can expect to see this appear soon.   Thanks! ... View more

Hi @diablo24 !   currently this information is not available in the dashboard API.   We already have a feature request for this endpoint to be added. Can you let us know your use case so we can better understand what you are trying to achieve so we can take this in to account with the current feature request.   Cheers! John ... View more

Hey @sungod !   While I don't have a definitive answer for you - I did do some testing to work out what the answer is.   I tested using the API call history endpoint which says that t0 is limited to the last 31 days.   What I found that it was actually 32 days from this second (right now). It seems the API server, as it is checking the parameters, checks the epoch time you pass to it with the epoch time from (32 x 86400 seconds ago).   I'm not surprised by the extra day - at Meraki, we nearly always under-promise and over-perform - this way no one complains when the "from today" is ambiguous! 😉   Going on to look at your use case, I would be tempted to build in redundancy in to your scripting, so you have duplication of data that you then de-dupe afterwards, or make the call more frequently, so you can always go back and get missing data later if it occurs. For me personally, this would be better than relying on having one call from your server once per months and then having no redundancy for any type of issue (anything from missing data, through to power failure on the server at the time you are making the call).   So I would do one of the following:   De-dupe model: Every week: - Get the last 31 days of data - De-dupe data   Utilise t1: Every week: - check when the last data was - t0 = the last data point (or 31 days max) - t1 = now - check for any duplication at the start of the data set (possibly an overlapping second at the start)   As for a definitive answer to what "from today" means, let's wait to see if one of my colleagues in the API engineering team reply 😄 ... View more

Hey @JudgeyK    The way that it works is that the data is sent up the Meraki cloud via the encrypted tunnel from each AP. Then depending on the version you are using for the location analytics, the following happens: - V2: you will receive a stream of data of every client that has been seen over the last minute (or so) from each access point. - V3: you will receive a stream about once a minute of aggregated data of all clients from all access points on a network-wide level.   Either way, the data originates from our public IP and is sent to the web server you specify. Therefore, your web server needs to be publicly accessible to receive the stream.   Once it is all set up, you will then receive a stream of all client details (including latitude/longitude) in JSON format.   It is worth remembering that to accurately give you these details, you will need to position your APs and Cameras on the map/floor plan as accurately as possible.   References:  https://developer.cisco.com/meraki/scanning-api/#!introduction https://documentation.meraki.com/zGeneral_Administration/Monitoring_and_Reporting/Using_a_Floor_Plan_or_Custom_Map_in_Dashboard https://documentation.meraki.com/MR/Monitoring_and_Reporting/Location_Analytics   Cheers! John   ... View more

Hey @cgarrido !   Similar to what @PhilipDAth said.   I chucked your code in to an environment to test, and it works fine for me.   It's more likely to be an issue with your key, rather than your network ID (but check both).   Cheers! John ... View more

I will bring this up in our next API team meeting and discuss with the product team.   In the meantime, you could create a support case and work with someone from the team to work out why you are getting bad connectivity with the gateway over meshing. ... View more

At the moment, this isn't available in the Dashboard API.   What is the use-case for it? ... View more