Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 
  • Community
  • Q&A
  • Jira
  • Questions
  • Unable to Retrieve User Email from Assets in Jira Service Management - 404 Error Despite Admin Privi

Unable to Retrieve User Email from Assets in Jira Service Management - 404 Error Despite Admin Privi

Eduard Diez
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
November 29, 2024

 

Hello Atlassian Community,

I am facing an issue when trying to retrieve user email information from Assets in Jira Service Management (JSM) via the REST API. Below is a detailed description of the problem and the steps I've taken so far:

Problem: I am trying to fetch user details, specifically the email, from an object in Jira Service Management's Assets. Although I am able to successfully retrieve the workspace ID and the objects within the workspace, I am encountering a 404 Not Found error when attempting to access the attributes of the objects, including user-related information (such as email addresses).

I am using a script to interact with the Assets API. The workspace and object ID are correctly recognized and retrieved, but when trying to access the attributes of a specific object (e.g., with object ID 79 or 80), the following error is returned:

GET request to /rest/servicedeskapi/assets/workspace/111111-1111111-11111111-11111/v1/object/79 returned an error code: status: 404 - Not Found

Steps Taken:

  1. Workspace Recognition:
    I can successfully list the available workspaces in JSM using the /rest/servicedeskapi/assets/workspace endpoint, and I verified that the workspace ID 111111-111111-111111-111111 fe is correctly returned.

    Example response:

    {
      "size": 1,
      "start": 0,
      "limit": 50,
      "values": [{"workspaceId": "11111-11111-11111-11111"}]
    }
    
  2. Object Retrieval:
    I can successfully list objects in the workspace using the /rest/servicedeskapi/assets/workspace/{workspaceId}/v1/object endpoint. However, when trying to access a specific object (e.g., object ID 79 or 80) with the /rest/servicedeskapi/assets/workspace/{workspaceId}/v1/object/{objectId}/attributes endpoint, I get a 404 Not Found error.

  3. Admin Privileges:
    The user executing the API request has been confirmed as a Jira Admin, but the issue persists. I verified that the user has the necessary permissions to access the object and its attributes.

Error Response: The error message returned when attempting to fetch the object’s attributes is as follows:

GET /rest/servicedeskapi/assets/workspace/111111-111111-1111111-1111111/v1/object/79 returned an error code: status: 404 - Not Found
body: java.lang.RuntimeException: com.fasterxml.jackson.core.JsonParseException: Unexpected character ('<' (code 60)): expected a valid value (JSON String, Number, Array, Object or token 'null', 'true' or 'false')

This error seems to indicate that the request is returning HTML instead of the expected JSON data.

 

If I use this script the workspace is shown in the logs well

 

def response = get("/rest/servicedeskapi/assets/workspace")
.header('Accept', 'application/json')
.asObject(Map)

if (response.status == 200) {
logger.info("Workspaces disponibles: ${response.body}")
} else {
logger.error("Error al obtener workspaces: ${response.status}")
}
println("Estado HTTP: ${response.status}")
println("Respuesta completa: ${response.rawBody}")

 

What I Have Tried:

  1. Verified Workspace and Object ID:
    I have double-checked the workspace and object IDs and confirmed they are correct.

  2. Permissions:
    I’ve ensured that the user running the script has full admin access and the correct permissions to access Assets data.

  3. Endpoint Check:
    I have also tested the endpoints in Postman and get the same 404 error, which indicates that it is not an issue with the script itself.

What I Need Help With:

  1. Why am I getting a 404 error when attempting to access the object’s attributes, even though the workspace and objects are correctly identified?

  2. Are there any additional permissions or settings in JSM that I might need to configure to access user data (like email addresses) in the Assets API?

  3. Could there be a configuration issue with the Assets API or something specific about the workspace or object that is preventing access to the attributes?

I am looking forward to your insights or suggestions to resolve this issue. If you need any more information or logs, feel free to ask.

Thank you for your help in advance!

1 answer

0 votes
Himanshu Tiwary
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
March 10, 2026

Hi 
I think the main issue is the endpoint/base url not the object itself

/rest/servicedeskapi/assets/workspace is the right call to discover the workspace ID, but the actual Assets object calls are documented under the Assets REST API base URL pattern:

https://api.atlassian.com/ex/jira/{cloudId}/jsm/assets/workspace/{workspaceId}/v1/object/{id}

and for attributes:

.../object/{id}/attributes

So if you are calling /rest/servicedeskapi/assets/workspace/{workspaceId}/v1/object/79 directly, that is likely why you get the 404 / HTML error page instead of JSON. Atlassian’s docs separate the workspace discovery endpoint from the object/attribute endpoints.

Also, GET object/{id} already returns the object with its attributes block in the response, so you may not even need the extra /attributes call unless you specifically want only the attribute list.

For the email part: even if the object is a user-type attribute, email visibility in Jira Cloud can still be restricted by Atlassian account privacy and permissions, so I would validate the object call first, then check whether the user data you need is actually exposed for that account.

So I would test in this order:

confirm the cloudId

call GET .../object/{id}

check whether the response already contains the user attribute values

only then test .../object/{id}/attributes

If this helped, a kudos would be appreciated.

Suggest an answer

Log in or Sign up to answer