Did return type for Jira Assets API change for 'created' property?

[Tim Dean]

I had some Jira API calls being processed and working before, where I call the object history endpoint, as documented in https://developer.atlassian.com/cloud/assets/rest/api-group-object/#api-object-id-history-get.

In the past, and according to the documentation, the response should have entries with a `created` property. The type of that property is listed as `string` with a `date-time` type. This seems to be an accurate description of how the API was working - until now.

I just tried to run my existing code, and it failed when parsing the JSON response from this API endpoint. Looking at the result I am seeing, the `created` property is now a number. In my specific example, I am seeing a value of 1746042290.281471000. This appears to be a unix timestamp value corresponding to Wednesday, April 30, 2025 2:44:50.281 PM GMT-05:00 DST.

Did the API specification change? Is the type of the `created` property now expected to be a number and the API documentation hasn't been updated? 

[Tim Dean]

For anyone curious about this, it appears that Atlassian has a new bug where the `created` field is incorrectly set. Refer to [JSDCLOUD-16619] Object History API returning incorrect created field - Create and track feature requests for Atlassian products. and [JSDCLOUD-16674] Assets objects history API endpoint retrieves created values in epoch format - Create and track feature requests for Atlassian products.

Apparently, this bug is currently manifested in some environments/workspaces but not others. For example, we have a sandbox environment where this bug occurs but our production Jira Assets environment does not (currently) have this bug.

[Tim Dean]

Further information from Atlassian support - This bug exists in the new architecture for Jira Assets and not the old environment. Some sites - like our sandbox environment - have already been updated to the new architecture. Other sites - like our production environment - has not yet been updated to the new architecture.

If your site has been updated to the new architecture then you should expect to see this bug until it is fixed. It is marked as a high priority bug so I would expect it to be fixed soon.

[Marc - Devoteam]

Hi @Tim Dean 

As you mentioned, indeed the API states this.

What is the code you are parsing (JSON)?

[Tim Dean]

I am first using a JSON-schema to validate and parse the JSON content. The original JSON schema I used declared this field as a string type. I could obviously change that to be a number type.

For the specific field, I am parsing the string using a date-time conversion function that expects a properly formatted date string. I could obviously change that parsing to expect a Unix epoch (seconds since Jan 1, 1970) time value.

What I'm trying to figure out is if those changes should be made. Has the API changed from what is in the documentation? If so, then it seems to be a recent change because I am pretty sure this code worked a couple of weeks ago.

Or is this an unintentional change in the API and something that should be considered a bug that will soon be reverted back to its documented format? I need to know the best way to make sure this code will work again and keep working.

[Marc - Devoteam]

No the API is not changed, based on what is stated in the documentation.

At least not that I'm aware of.

[Tim Dean]

@Marc - Devoteam Then that would mean there is a bug in the Atlassian's API implementation, correct? Can anyone else confirm that they are seeing this same bug? Or is it localized to our workspace somehow?

Is there a proper place to report bugs in the Atlassian APIs other than this forum?

[Tim Dean]

Update - I have discovered that I get different results between our production workspace and our sandbox workspace.

Our production workspace returns the correct date string format for the create property, matching what is shown in the API documentation.

Our sandbox workspace, which we use for testing out our integrations before deploying to production, is returning the incorrect field type for the create property. It is returning a unix date number value rather than a date string.

Clearly Atlassian has something going on in the back end and I will have to follow up with them to diagnose and fix the problem with our workspaces.

[Marc - Devoteam]

Hi @Tim Dean 

What if you overwrite your sandbox with production data?

Or is the field a different one in sandbox then prod, Would be something to check?

[Tim Dean]

@Marc - Devoteam Atlassian has confirmed that this is a bug with the API implementation and not something I can work around by copying data around.

[Marc - Devoteam]

Hi @Tim Dean 

But only relating your sandbox then, so a updated or newer feature causes the API to behave different.

[Tim Dean]

@Marc - Devoteam According to Atlassian, the bug is only present in sites that have been migrated to the "new architecture" for Jira Assets. Our sandbox environment got updated couple of weeks ago, and our production environment is scheduled to be updated next week. This bug will be propagated into our production environment soon, unless it is fixed before then.

[Tim Dean]

FYI - Atlassian has updated their bug tracking for this issue saying it is fixed. My quick tests confirm that it is working in our sandbox environment now.

[JSDCLOUD-16674] Assets objects history API endpoint retrieves created values in epoch format - Create and track feature requests for Atlassian products.