Confluence Cloud Content ID Semantics

As a Confluence Cloud developer, I found this documentation on Space Keys: extremely useful: Choose a space key | Confluence Cloud | Atlassian Support

This tells me that Space Keys:

  • Are Strings
  • Have a max length of 255 characters
  • Are Immutable

This tells me everything I need to know about Space Keys and what I would need to store them in a database/use them in code logic.

I’m looking for a similar resource about Content/Page IDs. Haven’t [been able to find an answer] so far. ([CONFCLOUD-72640] Documentation of content ID semantics - Create and track feature requests for Atlassian products.) As far as I can tell:

  • 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.

Thanks in advance!

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??

Hi @kashev,

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 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, 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.

Hope this helps.



Hi James,

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.


1 Like

Assuming Atlassian don’t change the format of the content ID to include non-number values or start using GUIDs.

My reading of Roman Toropov’s replays 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.