Jira integration/migration

Deepak Chawla

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.

Alexander Nilsson

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:

https://support.atlassian.com/atlassian-cloud/kb/401-unauthorized-error-when-service-account-accesses-jira-or-confluence-api/

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:

• Creating issues needs the write:jira-work scope on the token (classic scope is the simplest option).
• Adding attachments uses 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:

• The service account itself must have product access to Jira (added under Atlassian Administration, then granted access to the Jira app), in addition to the project role and permission scheme entries you already verified. Project permissions alone are not enough if app access is missing.
• The scopes you select on the token are independent from the project permissions. A token with only 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