Scoped API Key Does Not Work for Jira Routes

[Shaun Brazzoni]

This issue seems to exist on all routes, but my narrowed example is on this route:

/rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes

I can only use an unscoped key to access that route. If I use a scoped key I get the following error:

"{\"errorMessages\":[\"You cannot create issues in this project.\",\"You are not authorized to perform this operation. Please log in.\"],\"errors\":{}}"

I've created 4 keys with these permissions:

• read:jira-work (the only required classic permission defined here)
• every classic permission
• read:issue-meta:jira, read:avatar:jira, read:field-configuration:jira (the list of narrow permissions)
• write:jira-work, read:jira-work

Every key gives that same error. Am I missing something here?

Edit: This doesn't seem to be limited to Product Discovery. I get the same error when accessing a regular Jira project; I also get the same non-error using an unscoped key on that project.

[Philipp Sendek · Accepted solution]

Hi @Shaun Brazzoni ,

it is correct that when you use scoped API tokens, you will need to use a different base URL for your REST routes.
The first grey box on the following page shows the difference: https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/

## URL for API Tokens
curl -v https://mysite.atlassian.net --user me@example.com:my-api-token

## URLs for API tokens with scopes for Jira and Confluence
curl -v https://api.atlassian.com/ex/jira/{cloudId} --user me@example.com:my-api-token
curl -v https://api.atlassian.com/ex/confluence/{cloudId} --user me@example.com:my-api-token

If you scroll further down to the instructions on scoped API tokens, it will be explained once more with follow-up links.

I hope that helps!

Greetings
Philipp

[Shaun Brazzoni]

That looks like the right answer thank you! The docs might be a bit confusing for anyone entering through the developer.atlassian.com pages. It lists the {cloudId} route for 3LO Auth 2.0, but doesn't really have a dedicated section for API keys. The Ad Hoc section seemed to match my use case, and links out to API key creation.

Might be equally confusing for users on the new service account + Auth 2.0 system. The docs suggest the {cloudId} route for 3LO specifically, but elsewhere on the support pages, that route is mentioned to be part of the Auth 2.0 w/grant_type=client_credentials too.