Unexpected BSSID Format in getOrganizationWirelessSsidsStatusesByDevice API

[Spaz]

Hi everyone,

We're using the Meraki v1 API endpoint getOrganizationWirelessSsidsStatusesByDevice, and ran into an odd issue with one of our clients.

According to the official schema, the bssid field inside basicServiceSets is supposed to be a string:

"bssid": "string"

 However, in one of the responses, the bssid field was returned as a dictionary instead of a string. Here’s what we got:

"bssid": {
  "mac_address": "**:**:**:**:**:**",
  "enabled": true
}

Has anyone else encountered this? Is this a known bug or is there some undocumented behavior we should be aware of?

Appreciate any insight!

Thanks.

[alemabrahao]

This is correct, BSSIDs are hexadecimal values. A string does not necessarily mean that it will return text, a string can be made up of both numbers and letters.

Everything is ok with what the API is returning.

[alemabrahao]

What is BSSID?

An extended service set (ESS) has two types of SSIDs. First, there is the SSID for the entire ESS, which many sometimes be referred to as an Extended Service Set ID (ESSID). Within the ESS, each WAP has its own SSID, which is referred to as the Basic Service Set ID (BSSID). A BSSID is basically the MAC physical address of the wireless router or the access point. It is the unique identifier for a BSS. It is the Layer 2 identifier of each individual BSS. It is often confused with the SSID. But the BSSID is a 48-bit MAC address of an access point’s radio card. Some manufacturers allow for multiple BSSIDs to be connected to a single access point radio or a single common BSSID can be shared among many access points.

https://www.differencebetween.net/technology/difference-between-bssid-and-ssid/

[Spaz]

Thanks, but the issue isn’t about what a BSSID is.

The problem is that the API sometimes returns bssid as a string, and sometimes as a dictionary,

the fields like mac_address and enabled are not in the schema and causes breakage on our side.

This looks like a bug or undocumented behavior.

[mlefebvre]

These changes will happen all the time as there is an API release once a month, the best I can recommend is to
1) code defensively, knowing that the data you receive will change without warning on occasion
2) have unit tests you can run that check the expected return values of critical endpoints
3) have a lab org that is enrolled in the API early access program that you can test your code against as well

[Spaz]

Thanks, but this isn’t about handling evolving data — it’s about the API breaking its own schema.

Changing bssid from a string to an object without notice or schema update is a breaking change.

Unit tests shouldn't act as integration tests with real API responses.

And even with a lab org, we’ve seen different behavior in production vs test environments.

This kind of silent change needs to be documented and communicated properly. Otherwise, it’s just unreliable, we'll deal with it, but it's very disappointing.

[mlefebvre]

I get where you are coming from, what I am saying is that in my personal experience of working heavily with the Meraki API over 5+ years this is how it is sometimes just by its nature as an ever-evolving cloud product, I'm not sure what experience you have with other cloud products and their APIs but I have certainly worked with far worse than Meraki as far as sudden or undocumented API changes, and I would personally recommend taking the approach I already mentioned if you want to do something proactively to address these potential issues in the future.

[RaphaelL]

Hi ,

It happens all the time , a change is made to the API and the documentation is not updated.

Is the value returned in the dict valid ?

[Oren · Accepted solution]

That should not be happening.
I tried several organizations, and so far, I didn't find one where "bssid" returns a dictionary.

Can you share the organization ID where you see this? (a private message works too)

Thanks.