Projectvalidate/key and /name API unauthorized: Atlassian bug?


I am trying to use projectvalidate/key and projectvalidate/name APIs:

It’s working fine if I call it directly in a browser, but from my App, I get error response code 401 + ‘Unauthorized; scope does not match’.

I don’t understand because in the doc no permissions are required and scope is only ‘read:jira-work’ that I already have.

I tried it in the ‘Hello World’ app, same problem (with the get project API it works fine) :

import React from 'react';
import ForgeReconciler, { Text } from '@forge/react';
import { requestJira } from '@forge/bridge';

const response = await requestJira(`/rest/api/3/projectvalidate/validProjectKey?key=HSP`, {
  headers: {
    'Accept': 'application/json'

console.log(`Response: ${response.status} ${response.statusText}`);
console.log(await response.json());

const App = () => {
  return (
      <Text>Hello world!</Text>

    <App />

I see in the Forge example provided in the doc, it says

// This API resource doesn’t support Oauth2 (3LO). See alternate authorization methods:

and that’s a bit wierd, I don’t understand why being authenticated would prevent the API from working…

Have you experienced the same problem?
Thanks for your help :wink:

I have also tried with version 2 of the api.

And also to add all scopes in manifest.yml:

    - read:jira-user
    - read:jira-work
    - write:jira-work
    - manage:jira-project
    - manage:jira-configuration
    - manage:jira-webhook

I still wonder if there are some granular permissions that are not included in the classic permissions. I don’t find the documentation really clear on that subject:

I also tried to make the call from a resolver, same problem.

@BertrandDrouhard1 from what I understand, the requirement described in Path construction (route)was introduced some time ago. Your use of requestJira without a route-tagged template suggests that you are on an old version of the Forge runtime. Your entire request path may be getting URL-encoded, producing a request URL such as %2Frest%2Fapi%2F...

Support for lenient URL path processing for OAuth 2.0 requests was recently removed. Please see the removal notice and the deprecation notice for more details.

Thank you @epehrson. I have read that a few days ago (and seen many posts about it), I have checked it (looking for double / or things like that), and my path was okay. So I don’t think this is the reason why it does not work, and also because with any other Jira API, my code is working. It’s just those 3 endpoints that return that 401 error.

@BertrandDrouhard1 I would still suggest that you add the route-tag to the path, per the documentation. I’m honestly not sure why you’re not getting an error from the runtime without that tag.

If that doesn’t help, I would suggest raising a support request.

I think that ‘route’ is only needed when you call it from a resolver, but anyway I made a try on a resolver,

const res = await api.asApp().requestJira(route`/rest/api/3/projectvalidate/validProjectKey?key=HSP`);

and I still get the same 401 error, while it still works well for other endpoints like

const res = await api.asApp().requestJira(route`/rest/api/3/role`);

Where can I raise a support request?

@BertrandDrouhard1 > Bugs.



I got an answer yesterday from Atlassian support:

Looks like the endpoint you’re using rest/api/3/projectvalidate/validProjectKey doesn’t support Oauth2 (3LO) so the response you’re getting is expected. You can check alternative authorization methods here.

@epehrson , should we implement an alternative authorization method to use these APIs? And is it possible in Forge?

@BertrandDrouhard1 let’s follow up in the support request instead :slight_smile: