topic getOrganizationDevicesAvailabilitiesChangeHistory broken? in Network Platform API

getOrganizationDevicesAvailabilitiesChangeHistory broken?

sungod — Thu, 20 Feb 2025 10:42:02 GMT

With the deprecation and other issues affecting the getOrganizationDevicesStatuses endpoint, I'm finally getting round to redoing things to use getOrganizationDevicesAvailabilities and getOrganizationDevicesAvailabilitiesChangeHistory.

In testing, getOrganizationDevicesAvailabilitiesChangeHistory is returning out of time-bounds data, and what is returned looks weird...

Changes are returned that fall outside the bounds set by t0 t1, I'm using a one-day t0-t1 period in this instance.

Most 'changes' that are returned are not changes, i.e. old/new status value are the same.

This is from an org with a few hundred devices:

t0 2025-02-18T00:00:00Z

t1 2025-02-18T23:59:59.999999Z

old status	new status	timestamp
offline	online	2025-02-16T08:01:00.121999Z
online	online	2025-02-17T08:01:48.007999Z
online	online	2025-02-18T08:02:06.424999Z

The first two changes are out of t0-t1 bounds, the second two changes are not changes. I'm sure there was no such offline-online change on 16th on every device on every network.

Almost every device returns a similar triplet

It seems the endpoint is mostly returning spurious/bad data.

I decided to try with other orgs. Overall, on three orgs the endpoint is returning only t0-t1 in-bounds data, on three it is behaving as above.

But even on the three orgs where only data for 18th is returned, it is mostly 'changes' from online to online, it's not a change, why is it there?

I really have no idea what, if any, data can be trusted from this endpoint. Is this expected behaviour? It is not as I expect from documentation.

Can anyone from Meraki check/comment on this? I can PM org IDs.

Re: getOrganizationDevicesAvailabilitiesChangeHistory broken?

GreenMan — Thu, 20 Feb 2025 13:08:05 GMT

A case raised via Meraki Support would be the correct route for this kind of ask.

Re: getOrganizationDevicesAvailabilitiesChangeHistory broken?

sungod — Thu, 20 Feb 2025 13:24:58 GMT

Yeah, I know, but support always start with "prove it" and a default position that it's my fault.

Before I go down that route, I'd first like to know if this is expected behaviour, and/or if others are not getting the same results.

Re: getOrganizationDevicesAvailabilitiesChangeHistory broken?

inderdeepsingh1 — Thu, 20 Feb 2025 18:57:43 GMT

If i have the laugh button here, i will give you multiple laugh kudos 🙂

Re: getOrganizationDevicesAvailabilitiesChangeHistory broken?

theodore_ottesen@comcast.com — Tue, 25 Mar 2025 19:29:34 GMT

Were you ever able to get an answer on this? I’m seeing the same thing, and it’s going to be an issue when I switch all of my services over to this call and the history takes 10x as long to return than the availability call.

Re: getOrganizationDevicesAvailabilitiesChangeHistory broken?

sungod — Wed, 26 Mar 2025 08:57:54 GMT

After hitting the problem, I gave up on the history endpoint as the priority was moving off the deprecated getOrganizationDevicesStatuses which has been having issues affecting our customer reporting.

Now I'm just polling https://developer.cisco.com/meraki/api-v1/get-organization-devices-availabilities/ it seems to be working correctly. Switched over to this the last week of February and next week we will be doing a full month cross-check against our independent service management platform to see if the two match.

Re: getOrganizationDevicesAvailabilitiesChangeHistory broken?

theodore_ottesen@comcast.com — Wed, 26 Mar 2025 11:50:17 GMT

Got ya. Well I reached out to my contact at Meraki and I’m going to provide them with a ton of data on the issues this morning and he’s going to engage the product team. They were not aware of the issue, so hopefully we find the root cause and they can get it fixed. I’ll keep you updated.

Re: getOrganizationDevicesAvailabilitiesChangeHistory broken?

GreenMan — Wed, 26 Mar 2025 12:06:58 GMT

At the risk of receiving some 'feedback'... the product team would likely have been aware, had the case been raised with Support. I understand that this only comes accompanied by providing potentially quite a lot of information capturing the detail, all of which takes valuable time, but it really is the best (and only real official) path to raising a problem with the engineering team. Having a case reference (a parent case) helps tie everything together.

Re: getOrganizationDevicesAvailabilitiesChangeHistory broken?

quintmi — Tue, 26 Aug 2025 13:25:08 GMT

Has there ever been any feedback from support or the development team concerning the getOrganizationDevicesAvailabilitiesChangeHistory() function's working being investigated? Still noticing abnormal behavior when pulling change history via API, sometimes being able to go back 30 days, sometimes just a single day, it's not performing consistently.

If the data is natively available to be accessed via the API, I'd rather want to work with that data instead of having to setup my own monitoring infrastructure to poll the API every 5mins (not scalable for if you're managing many different organizations), besides, those are waaaay more API calls than just having to pull a single, nightly, change history log from Meraki itself.

Re: getOrganizationDevicesAvailabilitiesChangeHistory broken?

mabr1 — Wed, 08 Oct 2025 12:57:01 GMT

Same here - seeing issues with getOrganizationDevicesAvailabilitiesChangeHistory() working erratically and not returning the full target data, it is not consistent.