Now that we’ve set up our Service Account, we need to understand how to use it. As we identified in Part 1 of the series, Service Accounts sole purpose (for now) is to be used for API calls.
To help you get started, I’ve collected common pitfalls and errors, that I’ve encountered or been reported. Disclaimer: I am NOT a developer and by no means a specialist on APIs. So please correct me if I’m wrong and I’ll update this article for future readers.
There are two ways to access Atlassian REST APIs.
The most common and well documented one is the one, that includes your site url, followed by the specific request:
https://your-site.atlassian.net/{endpoint}
This way of calling the API cannot be used with scoped tokens. And as Service Account tokens cannot be created without scope, this API won’t work with them.
Luckily, there is another way via the api.atlassian.com base url, and most endpoints should work with that by now (not tested all).
https://api.atlassian.com/ex/confluence/{cloudId}/{endpoint}
https://api.atlassian.com/ex/jira/{cloudId}/{endpoint}
Rather than your site url, you need your Cloud ID to specify the target site.
💡
Find your Cloud ID by calling “https://<your-site>.atlassian.net/_edge/tenant_info", replacing “your-site” with your site url.
💡
The API Token can usually be sent in the Header as Bearer Token. It doesn’t need to be hashed and you don’t need the Service Account Email. The latter is only required for Basic Authentication which is not really recommended anymore but some endpoints still only work with Basic Auth and not with Bearer...
Example curl Code for listing all Confluence spaces, the Service Account has access to:
curl --request GET \
-H "Authorization: Bearer $TOKEN" \
--url "https://api.atlassian.com/ex/confluence/{cloudId}/wiki/api/v2/spaces?limit=250"
💡
Make sure to safely store the token.
Do:
Don’t:
💡
Wrong API version
Only the latest API versions support the needed base url format and scoped access. Unsupported endpoints will results in 404s or 403s.
Rate Limiting
Atlassian's APIs are rate-limited and breaching the thresholds is not uncommon for a multi-step/looped script. Make sure to catch status code 429 and build in wait times and retries.
Pagination
Some endpoints use pagination. You can identify them by looking at the request parameters.
Note: The Confluence and Jira APIs use DIFFERENT ways of pagination. While Confluence uses cursor-based pagination, Jira uses off-set pagination. The specifics are documented in each API overview section.
Confluence: https://developer.atlassian.com/cloud/confluence/rest/v2/intro/#using
Jira: https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/#pagination
Internal Redirects
Some endpoints internally redirect to a different URL. One example is the “Get Attachment” endpoint in Confluence. Per default, redirecting is usually disabled.
For curl, you need to set the “location” flag.
curl --request GET \
-H "Authorization: Bearer $TOKEN" \
--location \
For Python it is the “allow_redirects” flag.
response = requests.get('http://example.com/redirecting-url', allow_redirects=True)
Incorrect token scopes or permissions
If you keep getting 401 or 403 responses, check your token scope. For best results, start with a very specific token for that one endpoint and only set the granular scope that is required for that specific endpoint.
Remember that not only the token needs to match but also App level Permissions (license + content access).
Endpoint doesn't accept Bearer
Some endpoints (for whatever reason) don't work with Bearer. If you run into authentication issues and have ruled out everything else, try Basic Auth instead.
Using (Python) libraries
Ready-to-use Python libraries for Cloud, and probably most others, use the wrong API base url. As only the api.atlassian.net base url will work, the libraries cannot be used with Service Accounts. You can still use general Web Request libraries.
Trial and Error
That’s the part I don’t like. A lot of this is trial & error. If you cannot create endless Service Accounts and Tokens, it’s easiest to test everything with a personal scoped token first. If it works for that, then test with the same scope with a Service Account.
Also, test against a Sandbox or Test environment especially with Write-Requests. But that should be self-explanatory. Right?
Nothing special here. Rather than using your personal Account to send Web Requests, you can use your Service Account Credentials for calls against the Atlassian API.
Remember to add the Authorization Header. Hide the Header once your setup is done to make sure nobody can copy that token!
💡
You can use Smart Values in the request body as well as the url. Note that you need to url encode those values: https://support.atlassian.com/automation/kb/url-encode-jira-smart-values-using-20-instead-of-character/
💡
As per usual, Atlassian delivered Service Accounts at a state where they have not yet reached their full potential. So there still are a few things, that won't work.
The “Automation for Jira” user is a blessing and a curse at the same time. Before, you needed a “Technical User” Account to be able to mingle with anything Jira without traces back to yourself. Now, you can save a license and just use Automation for Jira. It has access to everything and virtually no limits. And that’s the problem. It doesn’t respect permission limits, even if a regular user is setting up the automation. Atlassian also realized that and rumors have it, that the Automation for Jira user will be deprecated in the near future. With Confluence Automation, Atlassian simply didn’t provide a “Confluence for Automation” user to begin with.
Service Accounts to the rescue. You’d think. Unfortunately, Atlassian doesn’t yet allow Service Accounts to be added as Rule Actors.
I’ve tried doing it via the UI, Rule Export/Import and updating the Rule via API. Everything failed. I also had the Support confirm this. So the only thing left to do is vote the feature request: [AUTO-2008] Ability to add Service Accounts as actors for Jira & Confluence Automation - Create and track feature requests for Atlassian products.
I also have a meeting with the Automation team in a couple of days so stay tuned for an update or part 4 :)
If you connect a Rovo Agent in your Automation, it will always use your user as a Connection. Meaning: Regarless of who triggers the Automation, Rovo will run with your access and permissions and return results respectively. I already flagged this as a risk for data leackage numerous times and am hoping that Service Accounts could become the answer to my prayers.
Update 2026-08-12: Agents are actually getting their own Account. "Agent Accounts" should already show up in most Orgs. They get their own set of permissions but don't have credentials. Rovo Agents can either continue to run with the current user's permissions or run as their own account.
Creating Service Accounts doesn't scale really well at the moment. I see the potential for some self service options where users can request certain things and Org Admins only need to approve. At the very least it would be great to see the Token Scopes and maybe the option to copy the token configuration.
Update 2026-08-12: There are new API endpoints that are offering some relief in that department. Full Self Service is still not possible but managing Service Accounts got a lot easier. Check out Part 4 for more info.
In case you missed it:
Part 2: Setting up a Service Account
I'm interested: What APIs have you used successfully with Service Accounts? Let me know in the comments and I'll add them to this article!
Rebekka Heilmann _viadee_
22 comments