Hi @KC Wong , @Arkadiusz Wroblewski covered the URL and header half correctly, so I will take the part you are actually asking about: why two credentials with the same two scopes behave differently. Short version: they are not being evaluated against the same scope list.
The three layers first, because the failing one is usually not the one people suspect. A service account can only perform an action if all three line up: product access (the account has Jira), permission access (it holds the role or permission in the space), and credential scope (the token is allowed to do that action). Your API token and OAuth credential share the first two layers, since they belong to the same service account. They differ only in the third, and that is where your error is.
Why the third layer differs: an OAuth 2.0 credential on a service account is checked per endpoint against the granular scopes listed for that endpoint in the REST documentation, and the scope catalogue available to the OAuth credential is not the same as the classic catalogue. Atlassian has confirmed this in a tracked bug for the JSM side, where classic scopes are not even offered during credential creation and each API call carries its own granular requirements: https://jira.atlassian.com/browse/JSDCLOUD-17697. The practical consequence: an endpoint that "works" under read:jira-work on one path can demand two or three additional granular scopes on the OAuth path, most often a user scope (any response containing user objects, which includes search and work item responses) and product-specific granular scopes. The clue you already found, that a broader-scope token works while the two-scope token does not, is exactly this: the endpoint needs a scope you have not granted, and the OAuth path is strict about it.
Diagnose it in two calls rather than guessing:
- Ask the token what it actually holds:
GET https://api.atlassian.com/oauth/token/accessible-resources with your Bearer token returns the site and the scopes attached to that token. Documented here: https://developer.atlassian.com/cloud/jira/software/oauth-2-3lo-apps/
- Open the REST reference page for the exact endpoint you are calling and read its OAuth scopes required block. It lists classic and granular scopes separately. Add every granular scope listed for that endpoint to the credential (you cannot edit scopes on an existing credential, so create a new one: https://support.atlassian.com/user-management/docs/create-oauth-2-0-credential-for-service-accounts/), then retest.
Two boundaries worth knowing. If your endpoint is under /rest/servicedeskapi/, you are inside the JSDCLOUD-17697 bug and the OAuth credential may simply not be able to satisfy it yet; the scoped API token is the working path until that is fixed. And for either credential type, the gateway URL form matters: scoped tokens only work against https://api.atlassian.com/ex/jira/<cloudId>/..., never the site URL, per this KB: https://support.atlassian.com/atlassian-cloud/kb/401-unauthorized-error-when-service-account-accesses-jira-or-confluence-api/
If you share which endpoint returns the error, I can point at the specific scopes it is missing.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.