API SSID reporting on MX vs. MR

[Gordon-HoC]

Hello, I've got many offices to report on via API. Some large offices have one or more MR AP devices, but small offices only provide wifi via their MX. I need to report on SSID configurations for all.

I've been happily using the API for many queries now with the proper key, org id, network id, etc.

I can retrieve the SSIDs for a large office with an AP by using the API command:

/networks/{networkId}/wireless/ssids

This corresponds to the SSIDs I see in the dashboard under the large template's Wireless|SSIDs tab.

However, for a small office with only an MX for wireless, the command above returns no records. This corresponds to the dashboard because the small template has all those SSIDs disabled. For these offices, I can instead find the enabled SSIDs on the Security & SD Wan|Wireless Settings tab. So they are there, but different.

I just can't find an API command that will return that SSID information - please help!

All signs point to the Get Network Appliance SSIDs command: /networks/{networkId}/appliance/ssids

But when I try that command I can only get a "bad request" returned.

Any thoughts or insight would be greatly appreciated!

(Small note... if I try to use the dashboard to look at the wireless information of a small office, the wireless tab is absent completely. But if I instead switch to a large office, then browse to the Wireless|SSIDs tab, then switch back to a small office, the page remains and I am able to see the SSID information for the small office! (so weird))

[mloraditch]

I just ran the https://developer.cisco.com/meraki/api-v1/get-network-appliance-ssids/ on an MX I have with wireless enabled and it returned fine.

I'm using postman if that helps.

There I think is an issue right now with certain types of networks not returning some API commands properly. I'm having issues finding a relevant thread, but I think it was something with networks where the ID started with L instead of N?

Support may be able to confirm if that's the issue you are experiencing.

As to the back and forth thing you are noticing with Wireless being there and sometimes not, I've seen that where a network is combined but doesn't actually have the product type in question. The GUI hides the irrelevant products but if you flip back and forth you can sometimes make the pages show up. It's harmless but yes it's dumb. You can split the network and then delete the unused product categories if desired.

[Gordon-HoC]

Thanks for your response!

My Network ID definitely starts with L 😕 These are MX68CW-NA devices located in Canada but using the American .com cloud.

I can get other appliance commands to work such as: /networks/{networkId}/appliance/ports

Will having support confirm that my network has the API command return problem get me anywhere?

I'll pass your suggestion in the last paragraph to my networking guys to see what they make of it.

[mloraditch]

Contacting support will at least tag your case to the issue so you get notified of the fix and having more people complain usually increases the priority of a fix being made so it may not help you immediately but it helps.

[danielpacheco613 · Accepted solution]

Hello @Gordon-HoC you mentioned the use of templates. This API call is not supported if you use templates. See output below.

{

"errors": [

"Unsupported for networks bound to a template"

]

}

[Gordon-HoC]

Postman does return that more specific error!

When I query via a Powershell Invoke-RestMethod I only get the more generic "400 Bad Request" which told me nothing 😕

I'll have to see if I can expose that better detail in Powershell.

In the meantime, I'll have to see if I can get the SSID information out of the template instead of the network. I'll post back with my results.

Thanks so much for your help!

[Gordon-HoC]

Well that's fascinating!

The API was happy to let me substitute the Network ID with a Template ID no problem.

Both the wireless/SSIDs command AND appliance/SSIDs command returned the proper values.

I'm back in action! Thanks so much!

[Gordon-HoC]

I appreciate the rapid help with my problem. I thought I'd try to contribute a little something...

Powershell isn't the best at providing full error details from a web request. Here's some code that goes the extra mile and extracts the error details such as "unsupported for networks bound to a template" (it has been simplified, but the key bits are here):

  Try
  {
    $MerakiResponse = Invoke-RestMethod -Method Get -Uri "$($URL)$Query" -Headers $Headers # Submit the query to Meraki and pass back the results.
  }
  Catch
  {

    $ErrorCode = $_.Exception.Response.StatusCode.value__  # Get the error code
    $ErrorDescription = $_.Exception.Response.StatusDescription # Get the error message

    # Process the error stream to extract the error details...
    $ErrorStream = $_.Exception.Response.GetResponseStream()
    $ErrorReader = New-Object System.IO.StreamReader($ErrorStream)
    $ErrorFullDetail = $ErrorReader.ReadToEnd()
    $ErrorDetail = $($ErrorFullDetail -split """")[3]

    write-host "Error: ($ErrorCode) $ErrorDescription`r`nDetail: `r`n$ErrorDetail"
  }