# Prerequisites - [X] I have searched [open](https://github.com/OctopusDeploy/Issues/issues) and [closed](https://github.com/OctopusDeploy/Issues/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aclosed) issues to make sure it isn't already requested - [X] My team has started working on this issue - [X] I have written a descriptive issue title # Summary The current Jira integration only supports the legacy authentication approach, which requires a dedicated Jira user with broad permissions and uses the instance-direct URL (https://<yourinstance>.atlassian.net). We need to add support for Jira's newer granular API tokens, which use a different base endpoint. ## Background Jira's granular (OAuth 2.0) API tokens route requests through: `https://api.atlassian.com/ex/jira/<cloudId>` rather than the instance-direct URL the integration currently uses. These two authentication approaches are not interchangeable — the endpoint itself is different, so supporting the new token type requires handling both URL patterns. ## Problem Customers who want to use granular API tokens (which allow scoped, least-privilege access) are currently blocked. To use the integration at all, they're forced to: Create a dedicated "dummy" Jira user Grant it broad/full access to work around the limitations of the legacy token approach ## Requested change Update the Jira integration to support granular API tokens by: Accepting a Cloud ID (or deriving it automatically) when a user configures the integration Routing API calls through https://api.atlassian.com/ex/jira/<cloudId> when a granular token is provided Ideally, allowing users to choose between legacy and granular token modes in the integration config UI