Meraki

John_on_API · ‎Sep 30 2024

You can now use the API to generate and revoke API keys. Reminder that your API keys belong to you, and not to any org or network. To generate a key: POST /administered/identities/me/api/keys/generate The response will include the API key. This is your only chance to record the key; it will not be shown in full ever again. If your user has access to many organizations, it could take several minutes for this operation to complete, and for the key to be accepted in every organization where you have access. Docs here. To revoke a key, use the key's suffix (its last 4 characters) in the following operation: POST /administered/identities/me/api/keys/:suffix/revoke If your identity has access to many organizations, it could take several minutes for this operation to complete, and for the key to be revoked everywhere. Docs here. To view non-sensitive information about your keys, you can use the GET operation.

John_on_API · ‎Sep 30 2024

Please do report this to support.

John_on_API · ‎Sep 12 2024

I'm surprised nobody recommended https://developer.cisco.com/meraki/api-v1/get-network-topology-link-layer/ -- which is purpose built for this kind of thing! And way easier than polling per-device discovery info.

John_on_API · ‎Sep 12 2024

Hi @MilosJovanovic taking off my employee hat and speaking as a civilian, this sounds a bit like unintended behavior. You might want to check with support on this -- imho, MQTT should use the same network ID that dashboard API uses. You might report this as "MQTT API doesn't use the network ID in topics" and point them to this thread. In the meantime, I think you'll need to use the device serial number, and poll getOrganizationDevices (you can filter on productTypes[]=wireless, if you only care about MR), to find out what the network ID of a given MR is. Putting the employee hat back on, this is a limitation on the MQTT side, and not a flaw with dashboard API.

John_on_API · ‎Sep 12 2024

Status, latency, etc. changes can be alerted on for WAN2 and other uplinks with the Meraki Insight feature set. I think it's included in the SD-WAN license tier.

John_on_API · ‎Sep 10 2024

I do not understand--you should not need to reprocess the entire organization if you are using the changelog operation (getOrganizationConfigurationChanges), which would give you, at the top of its response, an entry like this, if someone changes the name of a device: { "ts": "2024-09-10T23:13:53.834424Z", "adminName": "Person Name", "adminEmail": "your@email.address", "adminId": "0", "networkName": "NETWORK NAME", "networkId": "L_000000000000000000", "networkUrl": "/URL_HERE/manage/usage/list", "ssidName": null, "ssidNumber": null, "page": "Cellular Gateways", "label": "Updated name", "oldValue": "bc:db:09:00:00:00: OLD NAME", "newValue": "bc:db:09:00:00:00: NEW NAME", "oauthClientId": null } With the old/new value attributes you not only have the MAC of the device, you also have both the new and the old names. Why would you have to reprocess the entire organization?

John_on_API · ‎Sep 10 2024

In addition to @Kevin_R's advice, AirMarshal SSIDs, rules and settings are all queryable via API: https://developer.cisco.com/meraki/api-v1/search/?q=airmarshal

John_on_API · ‎Aug 27 2024

Hi @semsem2050 I don't see any obvious explanation for the issue. I recommend working with Meraki Support to help triage the issue.

John_on_API · ‎Aug 23 2024

Hi @semsem2050, thanks for asking! Exciting to hear that you're using Ansible. Just curious, are you using Meraki's official Ansible modules or rolling your own? The following are prereqs for claiming a subscription into an organization: You must be an org-write admin. The organization must not have any active co-term licenses. It sounds like you are using the correct operation, claimAdministeredLicensingSubscriptionSubscriptions . If I had to guess, you might not have org-write admin privileges. But hopefully the above helps nail it down. It would also help if you try to recreate the issue in Postman--taking Ansible out of the equation. That way you're not simultaneously troubleshooting both an API error and a possible Ansible issue.

John_on_API · ‎Aug 23 2024

I think your best bet is a prompt return to the auctioneer, presuming they sold them as either "unclaimed" or something other than "for parts." They are not re-usable without the prior owner unclaiming them. Secondhand and greymarket sales aren't supported. This is an issue between you and the auctioneer, not with Meraki support.

John_on_API · ‎Aug 22 2024

This suite of operations are another option: https://developer.cisco.com/meraki/api-v1/get-organization-wireless-devices-channel-utilization-by-network/ https://developer.cisco.com/meraki/api-v1/get-organization-wireless-devices-channel-utilization-by-device/

John_on_API · ‎Aug 22 2024

Great question, and good call using the org changes operation. This is a super efficient way to determine if changes have happened in an org. However, could I ask why even a minor change triggers processing of the entire organization?

John_on_API · ‎Aug 22 2024

No, you can run these API operations instead. I like the one in Early Access a little better: GA: https://developer.cisco.com/meraki/api-v1/get-network-policies-by-client/ EA: https://developer.cisco.com/meraki/api-v1/get-organization-policies-assignments-by-client/ FYI @PhilipDAth

John_on_API · ‎Aug 22 2024

Thanks for this rec! I'd like to explain why this is not the case, and why similarly, there's no CREATE action for a device. Devices in this sense refer to the physical hardware, so the concept of CREATING or DELETING a device is awkward. This is unlike a Docker cluster, an EC2 instance, a virtual device of some kind, etc. which could be CREATED or DELETED on a whim, which is where I imagine the expectation arises. getDevice & updateDevice (or even better, getOrganizationDevices & updateDevice) manage the attributes of the device, but the resource itself is never created or deleted. Although, that would be a pretty powerful operation if it could CREATE an MS355 out of thin air. Sign me up! Dashboard claim and release operations are represented in API as functional resources, rather than CRUD operations, which is an accurate depiction of what's happening. Forcing functional operations into the format of a CRUD suite can be awkward at best and confusing at worst. In short, not every REST operation is part of a CRUD suite! I hope this helps.

John_on_API · ‎Aug 22 2024

Hi @Aiden521, there is some nuance we can improve by updating the description for the operation. This operation should be described as follows, and work is underway to update the description so the docs are up to date: List the authorized users configured under Meraki Authentication for a network (splash guest or RADIUS users for a wireless network, or client VPN users for a MX network). While the operation name and path is a little confusing, this operation mostly operates on the authorizations of said users in the context of a specific network, and isn't true CRUD for the users themselves. So unauthorized users won't be returned in the API response. Thanks for asking, and hopefully this helps!

John_on_API · ‎Aug 22 2024

Hi @CCNA (slick name, btw!), The screenshot is super helpful. Unfortunately I don't think this is exposed via API at the moment--however, you can work with your account rep to open a feature request for this. A good way in general to check for these things is to check the API Index, where you could type in "country" as a response attribute and find all the operations that return it. This is how I for example checked whether this was exposed. Kindly, John

John_on_API · ‎Aug 22 2024

from meraki import meraki Instead, use: import meraki

John_on_API · ‎Aug 2 2024

Hi @252_Masked_Nett are you sure updates are allowed to that path? Please check the documentation and confirm. I suspect it's a read-only operation.

John_on_API · ‎Jul 9 2024

Thanks for sharing this request! Please work with your account rep to open a feature request at your convenience.

John_on_API · ‎Jul 9 2024

If you are experiencing this issue, please contact Meraki Support to resolve.

John_on_API · ‎Jul 9 2024

Please open a case with Meraki Support, especially if you have a means of reproducing the issue on-demand!

John_on_API · ‎Jul 9 2024

Re: getNetworkPiiPiiKeys - 400 Bad Request, {'errors': ['Please provide exactly one of username, email, mac, serial, imei, bluetoothMac']} This error message seems clear and actionable, so please let us know if following the error message's guidance doesn't work. I see that the descriptions of the query parameters do not explain that one of them is needed. The individual query params cannot be marked required, because not all of them are required (OASv3 is quite binary in that way). One way for this to be handled is for Meraki to update the description of the operation to include this guidance. Please work with Meraki Support to open a documentation fix case, so the relevant team can update the documentation to explain the necessary inputs.

John_on_API · ‎Jul 9 2024

Unfortunately, there are edge cases where networks don't have more than one product type (e.g. wireless only network). And in that case, the product type query parameter isn't required. The documentation is correct and complete, but there are certain scenarios where the docs need to be read more carefully, like this one. In any case, it's best practice to fully read the docs for any operation you're using. I hope this helps.

John_on_API · ‎May 28 2024

I might post in the Switch forum for a more specific answer. I think port profiles (not switch profiles) are more flexible in most cases.

John_on_API · ‎Apr 24 2024

Python 3.8's end of life date, October 2024, is quickly approaching! That means you should be in the process of upgrading your critical platforms to a newer version of Python, and we recommend 3.10, which offers a number of great new capabilities which are not offered in earlier versions (even 3.9), and has been GA for almost three years already. Some components of the Meraki Python library already currently require Python 3.10+ because they take advantage of the improvements in this version, whereas others require 3.8+. In light of the upcoming 3.8 end of life date, as well as other planned enhancements, we will be simplifying this requirement and enforcing Python 3.10 or newer for the entire library on or before the Python 3.8 end of life date. The upshot: Existing revisions of the Meraki Python library (up to v1.45.0) will not see changes to their existing Python version requirements. If you do not need to upgrade your Meraki library to take advantage of new features added to the Meraki API, then our requirements changes will not impact you. New features released after v1.45.0 will only be available to newer library revisions which will soon enforce the 3.10+ requirement. As always, please feel free to ask any questions here.

About John_on_API

John_on_API

Community Record

Badges