Meraki

daniel_abbatt

So I understand from your statement that if it gets a 400, 401, 403, 404, 500 or 502 it will not attempt redelivery for all these codes?

daniel_abbatt

What is the response handling on the Meraki side when it has sent a Webhook under the following conditions: - 5xx - 404 - 401 - 403 - Other 4xx - 2xx The reason I ask is under what conditions will Meraki attempt to resend Webhooks. I would hope it would let the user know in some way if the url appeared to be correct but the endpoint was returning a 401 implying that the shared secret was incorrect. I can see for the response codes above that Meraki might retry or not. I assume a 5xx would be retried a few times, maybe with a back-off? I couldn't find anything in the documentation as to how to respond to a webhook on a custom server.

daniel_abbatt · ‎May 14 2024

It's a funny one with secrets in the API. On the one hand I understand why they don't allow downloading them but on the other hand if you have permissions to upload a new one and replace it with your own, then why wouldn't you have permissions to download the existing one. As it currently stands we store various secret separately and when we hit endpoints that require uploading secrets then we apply them from our secret store at that point.

daniel_abbatt · ‎Sep 11 2023

You can make a call to the identities endpoint to see which user is associated with the current API key https://developer.cisco.com/meraki/api-v1/get-administered-identities-me/ Then you can use that email to correlate with the admins endpoint and see what orgAccess you have. https://developer.cisco.com/meraki/api-v1/get-organization-admins/ As noted already, there may be further restrictions on what you can do in a particular network, i.e. with cameras.

daniel_abbatt · ‎Jun 13 2023

Thanks, that sounds excellent; we use the spec internally to validate all our strongly typed interfaces to make sure we've got the request/response models correct etc and of course this only fully works for those that have been specified so anything in this area is welcomed. I can't remember what the spec allows but another thing we struggle with is whether a property on a response object will always be there or whether sometimes it isn't, and/or when it is can have a null value. We currently have to guess which response properties might be null and define our models appropriately, this useful for the consumer of the library as they'll know when to expect values or not.

daniel_abbatt · ‎Jun 13 2023

Thanks for this great work, looking forward to investigating in depth. Out of interest are the examples and models tightly linked and are they generated from code. I ask because in the past some examples have referred to fields not existing in the documentation and then the actual responses have included fields not present in either. So I guess I'm asking is the OpenApi definition code generated as part of the actual API methods and so will always be accurate to the underlying code generating the responses or is it hand crafted to an extent? I know there are so many different ways of generating OpenApi specs, e.g. from models and actions and comments. Thanks in advance.

daniel_abbatt · ‎Jun 9 2023

Phew good to hear! Thanks for the quick responses.

daniel_abbatt · ‎Jun 6 2023

Did you happen to notice if this was in addition to a product type 'switch' or whether it was instead of. Otherwise yes this would mean quite a few script changes for people I imagine.

daniel_abbatt · ‎May 25 2023

You should be able to see when VLANs are enabled by looking at the settings before you make a call to the VLANs endpoint. https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-vlans-settings It means 2 calls to the API to get VLANs though, so you may be better off just calling the VLANs endpoint and catching that error of 'VLANs are not enabled for this network'.

daniel_abbatt · ‎Apr 27 2023

Hi @Adrian4, that endpoint only allows individual VLAN creation. According to the action batches post you can create multiple entries per call using that mechanism. https://meraki.cisco.com/blog/tag/action-batches/ https://developer.cisco.com/meraki/api-v1/#!overview/action-batches

daniel_abbatt · ‎Apr 17 2023

While there isn't any documentation for the response, according to https://developer.cisco.com/meraki/api-v1/#!get-organization-devices-statuses there is a filter which allows the values for "statuses" while querying. It states: Valid statuses are ["online", "alerting", "offline", "dormant"]. So one could assume that these will be the only values returned.

daniel_abbatt · ‎Apr 17 2023

I think the API call being alluded to is https://developer.cisco.com/meraki/api-v1/#!create-organization-network passing in copyFromNetworkId with an appropriate value. Either way, neither functionality allows retrieval of all the entities created. The only way to back things up is to make the individual API calls.

daniel_abbatt · ‎Mar 29 2023

Yes it can. I don't have an example for you but if you Google using nuget packages with Powershell that should help.

daniel_abbatt · ‎Mar 28 2023

Is the network you created bound to a Configuration Template or is it unbound? It seems strange that the same definition for an unbound network should come back with different values. I kind of expect the network to return just "appliance" if it only has an appliance in it as that reflects the types of products actually present.

daniel_abbatt · ‎Feb 21 2023

Any news on when this can be fixed or an acknowledgement that the issue exists?

daniel_abbatt · ‎Feb 20 2023

https://developer.cisco.com/meraki/api-v1/#!get-organization-config-template-switch-profiles As noted in the WebEx MerakiBot notification: GET `/organizations/{organizationId}/configTemplates/{configTemplateId}/switch/profiles` response has changed response changed from [{'switchProfileId': '1234', 'name': 'A Simple Switch Profile', 'model': 'MS450-24'}] to {'switchProfileId': '1234', 'name': 'A Simple Switch Profile', 'model': 'MS450-24'} This is also reflect in the OpenApi JSON https://raw.githubusercontent.com/meraki/openapi/master/openapi/spec2.json Please revert this change as it is a list that is returned and is incorrectly flagging this as a difference in model compared to OpenApi Schema validation.

daniel_abbatt · ‎Jan 10 2023

It looks like the repo has been fixed in some way as the latest version is 1.29 and no longer 1.30. The release notes still only show 1.28 but the change log now includes 1.29 https://developer.cisco.com/meraki/whats-new/#!v1-29-0

daniel_abbatt · ‎Jan 9 2023

Which version is about to be released? It should be 1.29 I believe, but the repo https://github.com/meraki/openapi is showing 1.30 as being the current release. This repo is supposed to be the source of truth as per https://developer.cisco.com/meraki/api-v1/#!versioning Normally future versions would be on side/beta branches and main would be the current released version. According to the https://github.com/meraki/openapi/releases/tag/v1.29.0 tag, this was released on Jan 4th, but the changelog/release notes don't appear to be updated.

daniel_abbatt · ‎Apr 29 2022

Ah very nice. I was using https://petstore.swagger.io/ and pasting https://raw.githubusercontent.com/meraki/openapi/master/openapi/spec2.json into the source at the top. Yours looks good though - will investigate.

daniel_abbatt · ‎Apr 7 2022

Could we get some more and clarified documentation on what the new interfaceId is on the Network Appliance VLAN? The response documentation for https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-vlans shows it is a number, but an actual response shows it as a string? Please update the response documentation as I believe it is wrong. I assume this is the unique internal identifier which will can used by other endpoints to uniquely reference a specific VLAN. I think this must be the Ids which are returned by the switch static route endpoint which for IP offset definitions was returning the VLAN unique Id and we never knew which VLAN this was? Please clarify if this is the case. The following endpoints don't show the value in the example but the value is returned - Please update the response documentation to include interfaceId. Please update the documentation for the following responses: https://developer.cisco.com/meraki/api-v1/#!create-network-appliance-vlan https://developer.cisco.com/meraki/api-v1/#!update-network-appliance-vlan

daniel_abbatt · ‎Mar 24 2022

A small caveat to this is that you can of course only retrieve it if you HAVE a network bound to it.

daniel_abbatt · ‎Mar 21 2022

I believe I do understand and agree with what you're saying. That's not the issue I'm having though, can you explain why the same network retrieved via "/networks/nnn" comes back with different values to the same network entry in "/organizations/xxx/networks". To be clear - this is for a Config Template (appliance, switch, wireless) and Network that were just created and bound and the MX then added to the network. I understand the Config Template productTypes could be different from the Network productTypes at this point, but I don't understand why the same Network details retrieved from two different endpoints have different contents - this is unintuitive and so if there is a good reason then the documentation should state it, otherwise it's a bug I believe.

daniel_abbatt · ‎Mar 20 2022

Thanks for the responses and I understand what you're saying. In this case I am simply querying why the networks endpoint returns a different set of productTypes to the network endpoint. The networks endpoint is returning the config template product types whereas the network endpoint is returning the actual network productType. I can't see a reason why they would return different results so without documentation to the contrary, I'll just chalk this one up as a bug in the API response.

daniel_abbatt · ‎Mar 19 2022

https://developer.cisco.com/meraki/api-v1/#!get-network When I make a call to "/networks/nnn" I get the network returned with productTypes that take into account the devices on the network, i.e. with just an MX added, it has the single entry "appliance". { "id": "N1234", "organizationId": "xxx", "name": "Net1", "productTypes": [ "appliance" ], "timeZone": "Europe/Amsterdam", "tags": [], "enrollmentString": null, "url": "xxx", "notes": null, "configTemplateId": "CT4567", "isBoundToConfigTemplate": true } https://developer.cisco.com/meraki/api-v1/#!get-organization-networks The same entry in "/organizations/xxx/networks" shows the productTypes for the Configuration Template that the Network is bound to. In this case it's "appliance", "switch", "wireless". { "id": "N1234", "organizationId": "xxx", "name": "Net1", "productTypes": [ "appliance", "switch", "wireless" ], "timeZone": "Europe/Amsterdam", "tags": [], "enrollmentString": null, "url": "xxx", "notes": null, "configTemplateId": "CT4567", "isBoundToConfigTemplate": true } Which is correct and/or why are they different?

daniel_abbatt · ‎Mar 8 2022

Yup that did it!

About daniel_abbatt

daniel_abbatt

Community Record

Badges