Content IDs are in general numbers (like 4030503), but I’m not sure how big they can be (can I use a 32 bit integer to store them in a database? 64 bit? BIGINT?)
Content IDs returned by the Confluence Cloud API are Strings. Should I treat them as strings, not integers of some kind (even though the content of the string is an integer, perhaps it won’t be in the future?) If this is the case, is there a max length?
Are content IDs unique across type (e.g. a blog post can’t get the same page ID as a page, and the same with custom content)?
Are content IDs unique across the entire instance (they certainly appear to be, don’t appear to change when a page is moved from one space to another)
[less important] Are content IDs unique across confluence instances? I assume no.
I’ll also note that webhooks send content IDs as longs, but include an “ID as String” parameter. This makes thing murkier! Why would webhooks send me different data than the API??
Thanks for your questions. Let me see if I can answer them.
contentId is a long in the database (well, last time I looked it was). So they can get pretty big. Really big. Although they are returned as a String type in the json, unless you need to do math on them I’d recommend keeping them as a String, and the max length would be what the max length of a Java long would be.
They are unique per instance, so https://mycompany.atlassian.net/wiki will have unique contentId values. Content includes pages, blog posts, comments. They stay the same when content is moved. E.g. you’ll find some magic happening when a new version of a page is created, that the new pages gets the same contentId but the previous version will have a new contentId.
A different instance, https://myothercompany.atlassian.net/wiki will have its own set of contentId values. If you want a distinct key to use, then clientKey and contentId combined will give you that.
Thanks for responding! Another member of my team pointed me to this post, which I feel explains the issue in more detail.
Since my backend is in Java, it looks like I can safely store content IDs as long, and that will be safe for the forseeable future, and more performant on my backend as well.
My reading of Roman Toropov’s replys on the thread I posted implies that it would be a big deal on the Atlassian side to do that and they really don’t want to if they don’t have to:
We’re still using Java long internally in Confluence for representing IDs, and changing this would require a huge effort. Therefore it’s very unlikely that it’ll be changed in the nearest future. There must be a very good reason for that.