- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Meraki GET API: Need help with 400 Bad Request Errors
Hi Team,
Regarding the 400 Bad Request errors encountered while trying to perform GET operations on the following Meraki APIs:
- getNetworkPiiPiiKeys - 400 Bad Request, {'errors': ['Please provide exactly one of username, email, mac, serial, imei, bluetoothMac']}
As per the documentation mentioned here - https://developer.cisco.com/meraki/api-v1/get-network-pii-pii-keys/, the only mandatory parameter is networkid, which we are already passing. However, the command is returning an error, expecting additional query parameters. Is this expected behavior from the API, and is the documentation not up to date, or is this a bug on the API front?
- getNetworkEvents - 400 Bad Request, {'errors': ['productType is required']}
As per the documentation mentioned here - https://developer.cisco.com/meraki/api-v1/get-network-events/, the only mandatory parameter is networkId. However, the command is returning an error, stating that productType is required.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Lalena, for getNetworkEvents, productType is indeed required if your network is configured with multiple device types. When you create a network there is a option to create one with multiple device types or a single device type. In the latter case, this option is not required, hence it doesn't have "required" (mandatory) flag in the documentation. I hope this helps!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you. But isn't it supposed to fetch the network events for all the devices associated with that networkId in bulk instead of asking for producttype etc?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Lalena, this API delivers parity with [Network-wide] - [Monitor] - [Event log] in Dashboard UI. Right next to "Event log" title in UI, you will see a pull-down menu to specify product Type ("for security appliance" etc). If you specify "for access points" as an example, then it will give all the wireless devices in the same network. In API, this operation corresponds to specifying productType.
So it is supposed to fetch the network events for all the devices of "specified productTypes" with that networkId in bulk.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the detailed explanation.
However, on the UI, I tried the same path: [Network-wide] -> [Monitor] -> [Event log], and by default it is set to Access point -> Any , Event type include -> All, Client -> Any, etc. It does not throw any error even if there is no event log or something, but that isn't the same behavior while using the API. Not sure if I am checking the correct path on the UI.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The API is not Dashboard, do not assume that they work the same way.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was checking the comment that smarui mentioned.
Thank you all for the responses.
However, I believe that the API documentation should be updated to cover all scenarios and clearly mention the mandatory fields required to get the necessary information and make the API call successful. This would help avoid confusion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How would you represent it differently in the API documentation than it already is?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If productType is mandatory for multiple devices, then it should be mentioned under the mandatory field for more clarity, I believe. Because that's where those who are new to Meraki API typically look first.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the response John.
The APIs I posted are just examples; there are hundreds of APIs that are failing for the customer organization, and we're trying to determine the reasons at the same time struggling to understand the reason. During such widespread failures, it can be challenging to read through the entire documentation unless the necessary information/mandatory fields are clearly listed in the mandatory fields section. This is just my perspective as a new user of Meraki and its API. Nevertheless, we are in the process of evaluating each API failure and will decide which ones require support tickets once we have reviewed all the failures.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It sounds like there is something fundamental wrong.
We've used the API for many years across many organizations, whilst there are some calls that have issues, aside from transient errors which are to be expected, the Meraki API is pretty reliable.
I suggest explain what you mean by "hundreds of APIs that are failing ", which endpoints? which errors?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Currently, we are trying to filter out the error messages—specifically 400 Bad Requests that contain keywords like "not support," "unsupported," "not enabled," and "This endpoint only supports," as well as 404 Not Found and 403 Forbidden errors, since these are expected. Our goal is to identify errors related to missing parameters and similar issues since the customer is concerned about them. Once we have that, I will post them here.
