JIRA Cloud API returns 401 instead of 404
Asked by winterchillz:

Hi everyone,

I'm observing an odd behaviour with the JIRA cloud API when attempting to add or remove a watcher to/from an issue when the payload provided is not an accountId (ie, a username or an e-mail) as per the [documents.](https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-watchers/#api-rest-api-2-issue-issueidorkey-watchers-post)

The documentation states that if the user provided in the payload is not found, a 404 error will be raised, which is what I'd expect to see considering I've provided a malformed payload, however, the API instead returns a 401, which states that authentication credentials are missing, which is an incorrect error code given the circumstances.

This is what a valid call would be:

```
curl --request DELETE '<url of the instance>/rest/api/2/issue/<issue key>/watchers?accountId=<account ID>' --user <mail>:<token>
```

and, as expected, that returns a 204 code.

If you have happened to provide the wrong type of data for accountId (say, an e-mail instead):

```
curl --request DELETE '<url of the instance>/rest/api/2/issue/<issue key>/watchers?accountId=<email>' --user <mail>:<token>
```

I'd expect to receive either a 404 or maybe a 400, instead I get a 401 when my credentials are, in fact, valid.


Answers:
author: Andy Heinzer
body: Hi [@winterchillz](/t5/user/viewprofilepage/user-id/538614)

If I understand the concern here is that this REST API endpoint in question is returning a 401 when supplying an email address, instead of a different error code like a 404.

That particular endpoint is a bit different from other endpoints in the fact that each user can control their own watches, but there is an additional permission requirements are needed when managing any other users that might be watchers on that issue.

Unfortunately, the use of [email address and/or full name has been deprecated](https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-user-privacy-api-migration-guide/) for that endpoint for some time. Only the account Id is officially supported now. But I believe this can explain why supplying an email address here would return an authorization failure. Any value supplied here that isn't that user's own account id would require the system to do a check to see if the user making the call has ALL the permissions needed to remove other user.

That specific endpoint [noted response changes](https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-user-privacy-api-migration-guide/#issue) due to GDPR changes. Note that for the 'emailaddress' and 'displayName' fields, there is a note of "Depends on the privacy setting." Even though you might be a site-admin and org-admin, and have the project level permission to manage watchers, the end user in Atlassian Cloud today have additional privacy restriction options whereby they can choose to hide their email address from the admins in some cases.

Because of this privacy restriction, it's possible your account can't gain the permissions to lookup the user account by their email address alone via some REST endpoints, even though it might have been possible to do this at some point in the past before these GDPR changes. In this case, I expect that using the email address here would only be expected to work if the call is coming from that same user account OR the user account in question has selected to share their email address with you in their [personal settings on id.atlassian.com](https://id.atlassian.com/manage-profile/profile-and-visibility).

Moving forward, I'd always recommend using the account Id here.

I hope this helps.

Andy

comments: author: Brant Schroeder
body: Thanks Andy


author: winterchillz
body: Hey Andy, pardon the late reply, this indeed explains the behaviour, thank you so much both to you, for taking the time, as well as Brant for orchestrating the resolution to my query!


author: Brant Schroeder
body: [@winterchillz](/t5/user/viewprofilepage/user-id/538614) welcome to the Atlassian community

Are the credentials valid for that issue and what you are trying to do on that issue. For instance are you able add or remove a user with the credentials in the application as a watcher. Your credentials might allow you to login to the application but if you do not have the proper permissions on the Jira issue you would get a 401 error.

comments: author: winterchillz
body: Hi Brant, thank you!

The credentials are correct and contain the necessary permissions, the core of the issue I'm describing is the fact that the JIRA API returns the wrong HTTP code and I'm certain of that since providing the correct payload works.


author: Brant Schroeder
body: [@winterchillz](/t5/user/viewprofilepage/user-id/538614) if you are getting the proper information back when you submit a proper payload and it is broken when you send in a missing watcher. It sounds like a bug. I would suggest submitting it here: <https://jira.atlassian.com/secure/Dashboard.jspa?selectPageId=10440>


author: winterchillz
body: Hey Brant, thanks a lot for the tip!

I tried to file a bug ticket but I got an error saying:  

```
User '326843d41917' doesn't have the 'Edit Issues' permission
```


author: Brant Schroeder
body: [@winterchillz](/t5/user/viewprofilepage/user-id/538614) It looks like the bug submission just goes to the Atlassian support page. I will escalate it here since you are on the free plan.


Tags: api

cloud

jira-cloud