Updated URI for issue type and priority icons in REST API responses

What is changing?

Priority and issue type icon URIs that are included in REST API response objects will return an absolute tenanted URI in cases when iconUrl is referencing a static file from Jira’s /images directory.

Old response:

    "description": "Serious problem that could block progress.",
    "iconUrl": "https://api.atlassian.com/ex/jira/example-cloud-id/images/icons/priorities/high.svg",
    "id": "2",
    "name": "High",
    "self": "https://api.atlassian.com/ex/jira/example-cloud-id/rest/api/3/priority/2",
    "statusColor": "#f15C75"

New response:

    "description": "Serious problem that could block progress.",
    "iconUrl": "https://example.atlassian.net/images/icons/priorities/high.svg",
    "id": "2",
    "name": "High",
    "self": "https://api.atlassian.com/ex/jira/example-cloud-id/rest/api/3/priority/2",
    "statusColor": "#f15C75"

Why is it changing?

Those files are static assets and were never meant to be served via REST API.

What do I need to do?

Developers using this API will need to ensure they allow loading static files from tenanted URIs. Those URIs are available for everyone and do not require any authorization.

By when do I need to do it?

The change will be rolled out to the Jira ecosystem beta group on October 29, 2021 and will be rolled out to 100% of production instances by November 22, 2021.


@MikhailBogdanov thanks for this notice. Would you mind helping me with the following questions:

  1. Can you explain what this change looks like for custom issue type icons? Is the URL /images/icons/issuetypes/...?
  2. Does the URL for custom issue types require authentication?

We previously had issues with these icon URLs. The decision was that avatars should be private (refer to post here):

Both project and issue type avatars should be private and we will be rolling out a patch to ensure that’s the case within the next few weeks

Based on this, we introduced a proxy on our end to make sure we add authentication to avatar URL requests. However, your announcement now says:

Those URIs are available for everyone and do not require any authorization.

The current set of disconnected announcements (see another one here on project avatars) makes it difficult to understand what to expect from all these changes.

Could you shed some light on how the referenced announcements fit together? I am looking for the big picture, e.g. which avatar URLs require authentication and which ones do not.



@tbinna some issue types and priorities have predefined (default) icons that have a static URI looking like this: images/icons/priorities/high.svg or images/icons/issuetypes/bug.svg - those are just some static files that can be accessed by anyone and do not require any authentication. And that’s what this change is about - instead of returning a link to api.atlassian.com we will be returning it in a tenanted format (e.g. jira.atlassian.com/images/icons/priorities/high.svg).

Alternatively, iconUrl may look like this secure/viewavatar?size=medium&avatarId=10000&avatarType=issuetype - those URIs are not affected by this change, but they will be replaced with new APIs as described in the message linked by you - Updated URI for project avatar resources in REST API responses

These are 2 different changes that are in the same area, but they are not really connected.

The decision was that avatars should be private

We are not changing that and the API for fetching an avatar by object’s id will require authentication and appropriate permissions (as mentioned here), but for some objects (mostly priorities and some default issue types) icons specified as direct links to static files (/images/...) and they will be affected.

You can make a request to /rest/api/3/issuetype or /rest/api/3/priority and look at iconUrl property.


I like this change, as I found it strange that different API endpoints will return the icon urls either as absolute or relative url.

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