With the recently launched API Tokens with scope, there is also a change in the URL that is expected to be used:

When using scoped API Tokens, you can still use Basic authentication, but it has to use a different URL format. This difference in URL is now reflected in the documentation page Manage API tokens for your Atlassian account:

How to use an API token
A primary use case for API tokens is to allow scripts to access REST APIs for Atlassian cloud apps using HTTP basic authentication.

Depending on the details of the HTTP library you use, you can replace your password with the token. For example, when using curl, you could do something like this:

## 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

Currently, the personal API Tokens is indicating "API tokens without scopes are being deprecated" and suggesting using scoped API tokens, but it does not mention the difference in URL, which can lead to confusion and permission errors for using the mysite.atlassian.net format instead of the correct https://api.atlassian.com/ex/jira/<cloudId>.

For example, when sending web requests with API tokens with a scope, 

1. Create API token with scopes

   write:jira-work, write:issue:jira, write:comment:jira, write:comment.property:jira, write:attachment:jira, read:issue:jira, read:jira-work
   

1. Use the curl command with the API token created.

   curl -v --request POST
     --url 'https://ursite.atlassian.net/rest/api/3/issue/' I am running a few minutes late; my previous meeting is running over.   
     --header 'Authrorization Basic xxxxxxx' I am running a few minutes late; my previous meeting is running over.   --header 'Accept: application/json' \
     --header 'Content-Type: application/json' \
     --data '{
     "fields": {
       "description": {
         "content": [
           {
             "content": [
               {
                 "text": "Some Text.",
                 "type": "text"
               }
             ],
             "type": "paragraph"
           }
         ],
         "type": "doc",
         "version": 1
       },
       "issuetype": {
         "id": "10007"
       },
       "project": {
         "key": "KEY"
       },
       "summary": "Create a work item with CURL"
     },
     "update":{}
   }'
   

Results in a 401 response code:

* upload completely sent off: 476 bytes
< HTTP/2 401 
< content-type: application/json;charset=UTF-8
< date: Thu, 15 May 2025 11:19:56 GMT
< server: AtlassianEdge
< timing-allow-origin: *
< x-arequestid: 99d4d26cf5defbab62ef1e33d654402d
< x-seraph-loginreason: AUTHENTICATED_FAILED
< set-cookie: atlassian.xsrf.token=xxxxxxxx; Path=/; SameSite=None; Secure
.....
.....
{"errorMessages":["You do not have permission to create issues in this project."],"errors":{}}%   

"Get Work Item" also fails with a similar error

* Request completely sent off
< HTTP/2 404
...
* Connection #1 to host rchiquete.atlassian.net left intact
{"errorMessages":["Issue does not exist or you do not have permission to see it."],"errors":{}}%    

Other endpoints show different issues when using scoped tokens and the incorrect mysite.atlassian.net URL format. For example:

• GET /rest/api/3/project/ returns a 200 success but empty reply
• GET /rest/api/3/project/<ProjectKey or ID> returns a 404 project not found
• GET /rest/api/3/projectvalidate/validProjectKey returns a 401
• GET /rest/api/3/projectvalidate/key returns a 401 (Client must be authenticated)
• GET /rest/api/2/user/search returns 200 but gives an empty result.

Impact for third-party integrations

Another issue that arises from having a different URL for each token is that integrations with third parties might not be aware that there are two token types now, and when they ask for users to indicate an API token, they mean non-scoped API tokens, and in turn, they use the URL for that token type. Since there is no way to distinguish the type of token from the token itself, users might try indicating an API token with a scope, which will result in permission errors being returned. This leads to confusion and possibly users having to reach out to support, although this is ultimately something that has to be updated on the integration side by its vendor.

Request

The request here is to support both https://api.atlassian.com and https://mysite.atlassian.net when using scoped API Tokens. In addition, to also include the difference or hint about the documentation in the deprecation banner at the personal API Tokens page.