403 when migrating Jira Software REST APIs to /rest/software/1.0

Forge Adopting Forge from Connect
, ,
1

Hello,
We are migrating our Jira Cloud app from Connect modules to Forge. According to CHANGE-3193 (https://developer.atlassian.com/cloud/jira/software/changelog/#CHANGE-3193), the following Jira Software REST API is being deprecated:
/rest/agile/…/issue
We are trying to migrate to the recommended replacement:
/rest/software/1.0/…/issue
The deprecated endpoint works successfully in our current Connect implementation. However, the replacement endpoint returns 403 Forbidden when called from our Forge over Connect app.

Please note, it works fine for next version app from where we removing connect modules.

Our app declares the required scope:
read:jira-work and adding granular permissions do not help.
The app is installed on the same Jira site, and the user can access the relevant board/issues. We have also confirmed that the existing method works with the same user and site.
Could you clarify:

  1. Is /rest/software/1.0/… supported when called by a Forge app using Connect modules?

  2. Does the replacement endpoint require a different Forge or Connect scope?

  3. Is there an additional authorization, product access, or permission requirement?

  4. Is the 403 related to the new token-based pagination model or request format?

  5. Is there a known limitation or rollout status for these replacement endpoints?

    We are targeting publication of our migrated app version by the end of 2026. Our app will remain on Forge for Connect until November 1, 2026, which is also the removal date stated in the deprecation notice. We would appreciate guidance as soon as possible so we can complete the migration before the deadline.

Thank you

2

Hi @OleksandrVelytchenk1,

It works once the Connect modules come out, which points at which scope system is being consulted.

read:jira-work is a Forge scope and lives in manifest.yml. Connect uses a separate coarse set (READ, WRITE, DELETE, PROJECT_ADMIN, ADMIN) declared at the top level of atlassian-connect.json. The two share no vocabulary, so granular Forge permissions do nothing for a request being authorised on the Connect side. That fits your result.

Check what atlassian-connect.json declares, and whether that call is leaving with Connect auth.

One test separates it. Same request from a Forge resolver with api.asApp(), same site, same user. 200 puts the problem in the auth path. 403 means the scopes really are short.

Not reproduced on a Forge-over-Connect install, so treat it as where I would look.