Hi Team, I am working on a Jira integration/migration use case where I am trying to use a service account with an API token (Basic Authentication) to call Jira REST APIs such as creating issues and uploading attachments. Currently, everything is working perfectly when I use a personal user account with an API token, but the same APIs are failing when I use the service account API token. I have already verified that the service account is created correctly, the API token is valid, and I am using the correct authorization format (Authorization: Basic base64(email:api_token)). I have also ensured that the service account has proper project permissions like Browse Projects, Create Issues, Edit Issues, and Create Attachments, and it is added to the required groups/roles. Despite this, the APIs are still not working with the service account while they work fine with the personal account. I would like to understand if there are any differences in how service account API tokens work compared to user API tokens, if there are any additional configurations or limitations for service accounts in Jira Cloud, and whether there are any special requirements for using APIs like attachments with service accounts.
Also given all the permission.Any guidance on this would be helpful as I want to use a service account instead of a personal account for automation purposes.
Hello Deepak,
the symptom you described is a near textbook case of the difference between regular API tokens and service account tokens, and it is documented as such by Atlassian.
Service accounts can only create scoped API tokens, and scoped tokens do not work against the https://<your-domain>.atlassian.net/... base URL that personal API tokens use. They must go through the platform gateway:
So your call needs to look like this instead:
POST https://api.atlassian.com/ex/jira/{cloudId}/rest/api/3/issue
Authorization: Basic base64(service-account-email:scoped-token)
You can grab the cloudId for your site by opening https://<your-domain>.atlassian.net/_edge/tenant_info in a browser, it returns the JSON with the cloudId. The base authentication scheme stays the same, Basic auth with the service account email plus the token, but the host changes.
For your two specific calls:
write:jira-work scope on the token (classic scope is the simplest option).POST /rest/api/3/issue/{key}/attachments with X-Atlassian-Token: no-check and multipart/form-data, exactly as for personal tokens, just routed through the api.atlassian.com/ex/jira/{cloudId} gateway. The same write:jira-work scope covers it.Reference for the attachment payload format if you want to compare against your current request:
https://support.atlassian.com/jira/kb/how-to-add-an-attachment-to-a-jira-cloud-issue-using-rest-api/
Two extra checks worth running once the URL is correct:
read:jira-work will still fail to create issues even if the service account has Create Issue permission, because the scope caps what the token can do.Atlassian's guide on service account tokens covers the full flow including how to create a token with the right scopes:
https://support.atlassian.com/user-management/docs/manage-api-tokens-for-service-accounts/
I am really looking forward to your feedback :)
Greetings,
Alex
I have given all the role and given the service account api , then to getting error
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Deepak,
thanks for your feedback.
Can you share with us the used endpoint (without sensitve Data) and the exact error message?
Thank you and greetings,
Alex
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.