Change in the URL in Paginated results from api.meraki.com

[ag_scilo]

Have the URLs in the results for a paginated response been updated recently? as recent as last weekend( Jan07-2024) We are seeing returned URLs with "api.meraki.com" now, when we previously saw results like "n392.meraki.com"  or something similar.

Prior to last weekend , 100% of the times the URL on the first page was api.meraki.com but subsequent ones were non-api.meraki.com , mostly from n392.meraki.com or n69.meraki.com but since the beginning of this week we only are getting results from api.meraki.com all ALL paginated results. We have some labs with 5000 devices. 

This is an urgent request , please let us know what changed and if this is temporary .

[ConnorL]

Hello @ag_scilo,

Yes, this was changed a few weeks ago. It is best practice to always use api.meraki.com and not the specific Dashboard shard (e.g. n123), as this can sometimes change during/after maintenance - this is why the paginated links now use api.meraki.com.

If you're seeing issues since this change, e.g. 404/500 responses, please raise a support case.

Cheers,

Connor.

[ag_scilo]

Thank you @ConnorL . Many of our labs are impacted for sure . Could you give me some specifics please .Is there a Cisco release notes/case number/something external we can point to that shows this change?

[mlefebvre]

Please define what you mean by "impacted"

[ag_scilo]

Our code attempted to parse the URL in a pagination response where we parsing off the intermediate hostnames to replace them with "api.meraki.com", and now that the returned pagination URLs have been updated to use api.meraki.com, we no longer need to do so.  A link to a changelog of some sort from Cisco would help us track this matter better for posterity. 

[ConnorL]

I've reached out to the team responsible @ag_scilo to ask if there will be an entry on the API changelog, as soon as I've heard back I'll update this thread.

[dbaehr]

Hi @ConnorL Any updates on the documentation of the change? 

[John_on_API]

Hi @ag_scilo, thanks for reaching out, and sorry to hear that your lab script has started having issues.

Have the URLs in the results for a paginated response been updated recently? as recent as last weekend( Jan07-2024) We are seeing returned URLs with "api.meraki.com" now, when we previously saw results like "n392.meraki.com"  or something similar.

The contract around pagination URLs has not changed--pagination URLs should be treated as opaque strings as usual. Unless otherwise specified (e.g. as in a documented enum), the default assumption for any string value returned in API is that it should be treated opaquely.

In some cases, pagination URLs have included shard names (e.g. n392) but it's not reasonable to assume that this URL will follow a specific hostname format. Most pagination URLs will include something like api.meraki.com (or a hostname more relevant to your specific cluster), but again, that's not safe to assume in all cases, because these fields are not guaranteed to comply with a specific format beyond being a valid HTTPS URL for the purposes of pagination.

If you have code that expects the hostname to include a string such as n392, then it will likely fail in any case where the pagination URLs do not include such a string.

I hope this helps, and let us know if you have any other questions.

[TaylorJohnson]

Thanks Jon. Is there a newsletter or notification for API changes we can subscribe to? This has turned into a mess for us as this broke the integration for our customers. I had never concerned myself with it before now because I was under the impression that nothing would change in the API behavior unless it happened as a versioned change in a v2 URL for example. I assumed something we built for the v1 API would continue to work. 

[sungod]

The API specification is published here...

https://github.com/meraki/openapi

...you could subscribe to notifications from GitHub when it changes, then go to https://developer.cisco.com/meraki/whats-new/ to see more readable info.

[TaylorJohnson]

But the API spec didn't change from what I can tell. It was the contract for the API but it was behavior of the formatting of the URL that came back and I don't think that's part of the spec. 

[sungod]

Correct, the API spec didn't change.

The problem was due to relying on internal/private behaviour of an endpoint...

Like @John_on_API says above, the prev/next strings are opaque, they are only there for the API to manage pagination of an endpoint's response data, but they're not themselves part of that response data.

If Meraki change the way an endpoint does prev/next, that's internal, it doesn't affect the published spec, and code that does what the spec says will carry on unaffected.

[TaylorJohnson]

Do you know if the docs have always stated they are opaque? 

[John_on_API · Accepted solution]

Hi @TaylorJohnson,

The default assumption for any API (not just Meraki's) is that unless explicitly documented otherwise, the string is opaque. There's no contract in place that the URLs will take a specific format, beyond being usable URLs.

There is no indication in the OAS that the strings will have specific hostnames. Of course, if you find evidence of this, please do let us know so we can resolve that. 

Kindly,

John

[TaylorJohnson]

Okay, thanks John. 

[John_on_API]

Just to clarify--the formatting of the URL did not change. It's always been a string.