Atlassian Service Accounts

Atlassian service accounts let your workflows authenticate to Jira and Confluence as a non-human bot user — independent of any individual employee's account. Each service account has its own email, its own permissions, and its own API tokens, all managed centrally in admin.atlassian.com.

This is the recommended way to use Jira and Confluence in production workflows: no one person's OAuth consent expires, the bot's permissions are auditable, and access can be revoked without touching anyone's personal account.

Prerequisites

You need an Atlassian organization admin to create the service account. Service accounts are an Atlassian organization-level feature — they cannot be created from a regular user account.

Setting Up the Service Account

1. Create the Service Account

Open admin.atlassian.com and go to Directory → Service accounts

Click Create service account, give it a name (e.g. sim-jira-bot), and finish creation

Grant the service account access to the Atlassian sites and products it needs. Open the service account, go to Product access, and add Jira and/or Confluence on the relevant site

The service account inherits permissions from the project/space roles you grant it — exactly like a human user. If a workflow needs to write to a specific Jira project, give the service account write access to that project in Jira's project settings.

2. Create a Scoped API Token

From the service account's page in admin.atlassian.com, open the API tokens tab and click Create API token

Choose API token as the authentication type (not OAuth 2.0 — Sim uses the API token flow)

Select the scopes the token needs. The minimum set Sim's Jira and Confluence blocks expect is:

Jira (granular):

read:jira-user
read:jira-work
write:jira-work

Confluence (granular):

read:confluence-content.all
read:confluence-space.summary
write:confluence-content
read:page:confluence
write:page:confluence

Add more scopes only if you need the corresponding operations (delete, manage webhooks, etc.). The full list of scopes Sim's blocks may use is documented in Atlassian's developer reference.

Use the App and Scope type filters to narrow the list to the scopes you need. Filter by App: Jira (or Confluence) and Scope type: Classic to find the three core Jira scopes; switch to Granular if your org doesn't expose Classic.

Copy the token when it's shown. Atlassian only displays it once — if you close the dialog, you'll have to create a new token.

The API token is bearer credentials for the service account. Treat it like a password — do not commit it to source control or share it publicly. Sim encrypts the token at rest.

3. Find Your Site Domain

Your Atlassian site domain is the URL you use to access Jira or Confluence in your browser — for example, your-team.atlassian.net. Open Jira or Confluence, look at the address bar, and copy the part before the first /.

Adding the Service Account to Sim

Open your workspace Settings and go to the Integrations tab

Search for "Atlassian Service Account" and click it

Paste the API token, enter the site domain (e.g. your-team.atlassian.net), and optionally set a display name and description

Click Add Service Account. Sim verifies the token by calling Atlassian's /myself endpoint through the gateway — if it fails, you'll see a specific error explaining what went wrong.

The token, domain, and discovered cloudId are encrypted before being stored.

Using the Service Account in Workflows

Add a Jira or Confluence block to your workflow. In the credential dropdown, your Atlassian service account appears alongside any OAuth credentials. Select it and configure the block as you normally would.

The block calls Atlassian's API gateway (api.atlassian.com/ex/jira/{cloudId}/...) using the service account's token. There's no impersonation step — the service account acts as itself, with whatever permissions you granted it in admin.atlassian.com.

Common Questions

API tokens for service accounts don't have a 1-hour expiry and don't require any user to consent. They're issued by an org admin and are stable until you revoke them — which is what you want for an automated workflow.

No. Service accounts are an Atlassian organization-level feature and only an organization admin can create them.

Yes — give the service account access to both products on your site, and include scopes for both when you create the API token. Then connect it once in Sim and use it from either Jira or Confluence blocks.

Either widen the token's scopes (revoke it and create a new one with more scopes), or grant the service account higher project/space roles in Jira or Confluence. Scope failures look like 401/403 errors with descriptive messages.

Create a new token from the same service account in admin.atlassian.com, update the credential in Sim with the new token, and once it's working, revoke the old one.

No — this integration uses Atlassian Cloud's API gateway (`api.atlassian.com`). For Data Center, use the OAuth flow or set up a self-hosted bot user.