API: Organization IDs are larger than MAX_SAFE_INTEGER

BrianC
Conversationalist

API: Organization IDs are larger than MAX_SAFE_INTEGER

A bit surprising that the first API call I ran in Meraki gave me trouble.

 

I requested my organizations from /organizations, and I got back something like this:

 

[{"id":321786418483472292,"name":"sample"}]
 
But in Node.js, this parses as:
 
[{ id: 321786418483472300, name: 'sample' }]
 
...because the "id" is two digits longer than Number.MAX_SAFE_INTEGER, making it unparseable in Javascript. If you know you have a 64-bit integer, put it in JSON as a string, the way Twitter does.
6 REPLIES 6
DexterLaBora
Meraki Employee

This was noted and we are investigating the best way to address the issue. Essentially, the organization ID should be a String but is being sent as a Number. 

If we switch the type, it's technically a breaking change. That being said, it doesn't do you much good if the number is getting mangled by JavaScript. 

 

Stay tuned for updates on this.

 

 

FWIW, I have used json-bigint in the past to parse the JSON as a workaround.

 

 

You could add a second field id_str, which would avoid a breaking change.

 

At the moment I'm pulling the id out with a regex, which has got me going for now.

@BrianC 

 

Apologies for the dumb question, but how would I be able to implement the second field "id_str" ? 

Should I add it as a variable?

Should I add it somewhere else?

 

total new guy at Postman and running into this rounding issue.

@writ_er_relo  Either Cisco has to add a new string field, or you have to work around it. Here's what I did:
 
 
const idMatches = allMatches(/"id":(\d+)/g, body);

return JSON.parse(body).map((org, i) => ({
  id: idMatches[i][1],
  name: org.name,
}));
...where "allMatches" is a function that returns all matches for a regex on a string.

We plan to fix the incorrect type returned in the `/organizations` response. This was the only place where this ID appeared as a `number`. It was stated in our documentation that the org ID and all other IDs should be treated as a strings, but this ID was a little ambiguous with the JSON response.

 

This should not break any normal code, as long as you ultimately used the org ID as a string. Stay tuned, for an update shortly. Once it's implemented, we will make an announcement in this community. 

DexterLaBora
Meraki Employee

This is being fixed. Please refer to this post for more details.

https://community.meraki.com/t5/Solutions-APIs/Bug-Fix-Organization-ID-type-as-string/m-p/49840#M147...

 

 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.