Cloud Version Specifications

Question

Hello everyone,

I would like to consult you regarding the following matter.

◆ Situation

* We are currently planning a migration from the DC version (Jira Core) to the Cloud version.

* We have received a request to implement the following configuration:

◎ Proposed Configuration

・ Jira REST API

・ Authentication via Personal Access Token (PAT)

・ Executing the API from Excel Power Query

・ Storing the Excel file on SharePoint for use by multiple team members

・ Anticipated data update frequency: approximately 20 times per day

Based on the above, I have two questions:

* Is the configuration described above supported in the Cloud version?
* Could you please advise on any implications or differences compared to the DC version when using this setup in the Cloud?

I look forward to your responses.

Tomislav Tobijas · Answer

To chime in really quickly here, service accounts would probably be a recommended way to go. Rebekka did a great series about that and you can check it out here 👇

* Part 1: What they are (for)
* Part 2: Setting up a service account
* Part 3: Service Accounts in Practice
* Part 4: Token renewal

But apart from that, personal API tokens are also a possibility, as the guys have already said.

Cheers,

Tobi

Mihai_LeanZero · Answer

Coming from DC the workbook is probably on v2. That still works. The old /search is gone there as well but /rest/api/2/search/jql answers on cloud, and staying on v2 keeps descriptions and comments as plain text where v3 hands them back as ADF, which Power Query then has to flatten.

Users come back as accountId. No usernames, so any column keyed on one needs remapping.

If it shouldn't run as a person at all, a service account is the documented route. I'd check the org has them available first.

Josh · Answer

Hi @Moe Nishino , yes, this setup works on Cloud, but three things change compared to DC.

1. No Personal Access Tokens on Cloud. Cloud uses Atlassian account API tokens with Basic auth: Authorization: Basic base64(email:api_token). Create one at id.atlassian.com > Security > API tokens. Two differences from DC PATs:

* Tokens expire after 1 to 365 days (one year by default), so plan a renewal before the workbook stops refreshing.
* The token belongs to a person's Atlassian account, not to the Jira site. If that person leaves, the token stops working.

2. The search endpoint and paging are different. Use /rest/api/3/search/jql. The old /rest/api/3/search has been removed from Cloud. Paging uses nextPageToken instead of startAt/total, so your Power Query needs a loop: request a page, read nextPageToken, repeat until it's missing. Also ask for only the fields you need (fields=key,summary,status,...); otherwise you get very little back by default.

3. Shared workbook on SharePoint. Power Query stores credentials per user, not inside the file. Each person who refreshes needs their own API token entered in Data source settings. That's the right model anyway: each person sees only what their Jira permissions allow, and nobody shares one person's token. Don't hard-code a token in the M query of a shared file.

About 20 refreshes a day is fine. Cloud rate limits are far above that for a single JQL export, as long as you page sensibly (for example maxResults=100). If your org uses IP allowlisting, the requests have to come from an allowed network. Excel desktop calls from the user's machine; refreshes in Excel for the web or Power BI service come from Microsoft's IPs.