Temporary `idAsString` field in Confluence Webhooks

Hi developers!

We’ve added a new temporary field to some of the Confluence Webhooks.

What is changing?

Starting from May 1, 2022, webhooks listed below, in addition to numeric id field, also contain new idAsString field with the same id value, but in the string format. This field is temporary and is added to help with migration of the existing id field from number to string , which will happen in 6 months.

Example of a page_viewed webhook payload:

  "userAccountId": "<truncated>",
  "accountType": "customer",
  "page": {
    "idAsString": "153911297",
    "creatorAccountId": "<truncated>",
    "spaceKey": "~377712048",
    "modificationDate": 1588017393390,
    "lastModifierAccountId": "<truncated>",
    "self": "https://<sitename>.atlassian.net/wiki/spaces/~377712048/pages/153911297/Page",
    "id": 153911297,
    "title": "My Page",
    "creationDate": 1587664115472,
    "contentType": "page",
    "version": 4
  "timestamp": 1651525425754

What do I need to do?

If your app is strongly typed or in any other way won’t be able to process the id field if its type is changed to string (for example if you compare it to other values using === operator in JavaScript), please temporarily migrate your app to use idAsString field instead. You’ll need to migrate back to id field after its type changes. A separate announcement will be made before deprecating idAsString (follow up ticket).

If your app is able to handle the id field irrespectively whether its type is number or string please continue to use id field.

Why we’re doing it?

The change was made to address the issue with customers migrated from Server to Cloud, for which entity ids now start with an arbitrary big number that exceeds the maximum integer number value for JavaScript - 2^53 - 1 . This issue has been fixed, so no new migrated customers will have this problem, but customers migrated before this fix was rolled out, are still affected.

Affected webhooks

The following webhooks now contain idAsString field for page, blogpost, attachment and comment entities:

  • attachment_archived
  • attachment_created
  • attachment_removed
  • attachment_restored
  • attachment_trashed
  • attachment_unarchived
  • attachment_updated
  • attachment_viewed
  • blog_created
  • blog_removed
  • blog_restored
  • blog_trashed
  • blog_updated
  • blog_viewed
  • comment_created
  • comment_removed
  • comment_updated
  • content_permissions_updated
  • label_added
  • label_created
  • label_deleted
  • label_removed
  • page_archived
  • page_children_reordered
  • page_created
  • page_copied
  • page_moved
  • page_removed
  • page_restored
  • page_trashed
  • page_unarchived
  • page_updated
  • page_viewed
  • space_created
  • space_logo_updated
  • space_permissions_updated
  • space_removed
  • space_updated
1 Like

Hello @RomanToropov,
thanks for the heads-up.

What’s the expected range of the new id String field? Will it grow beyond 2^63 - 1 (Java long)?

Hi @ben2 ,
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.
For now we have more than enough room within Java long boundaries to represent all possible ID values.

If it’s ever got to change in future, it’ll definitely be communicated well in advance.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.