# Atlassian (Jira and Confluence)

## What it does

Atlassian connects Speedwave to Jira and Confluence. Speedwave can search and update Jira issues, move them through workflows, attach files from your project, work with Agile boards and sprints, and read or write Confluence pages, comments, and labels. Atlassian Cloud only: no Data Center or Server.

## What it consists of

Atlassian is a built-in worker: its own container, enabled per project from the Desktop app. Three credential values sit behind it, a site URL, an email, and an API token, stored on disk and mounted read-only. The project folder is mounted read-only too, at `/workspace`, so attachment uploads can read files straight from disk. Two optional allowlists, Jira project keys and Confluence space keys, narrow which projects and spaces it can touch.

## How it works

The worker authenticates as a real Atlassian account and can reach anything that account can reach, which is why the allowlists matter: set them, and operations outside the listed projects or spaces are rejected. Missing or invalid credentials put the worker into a "not configured" state: it keeps running, but every tool call returns a clear error until you fix them.

Requests pass from Claude through the [Tool Gateway](/docs/under-the-hood/tool-gateway/), which holds no tokens, to the worker, which mounts its own credential folder read-only and talks to the Jira and Confluence Cloud REST APIs directly.
**Use a dedicated service account:** The worker reaches everything the Atlassian account can reach. Use a dedicated service account with the narrowest permissions available, and set the allowlists, to keep the blast radius small if the token is exposed.

## What Speedwave can do

The worker exposes 35 tools: 22 for Jira, 13 for Confluence. One is destructive: `deleteAttachment` removes an attachment for good. Everything else only creates, reads, or updates.

**Jira**

| Tool | What it does |
|---|---|
| `searchIssues` | Searches issues with JQL, paginated by cursor (50 per page, up to 100). |
| `getIssue` | Gets one issue by key or numeric ID. |
| `createIssue` | Creates an issue with summary, type, description, priority, labels, assignee. |
| `updateIssue` | Updates summary, description, priority, or labels on an issue. |
| `getTransitions` | Lists the workflow transitions available on an issue. |
| `transitionIssue` | Moves an issue through a workflow transition. |
| `assignIssue` | Assigns or unassigns an issue. |
| `getMyself` | Returns the Atlassian account the worker authenticates as. |
| `addAttachment` | Attaches a file to an issue: the worker reads a path under `/workspace` and streams the bytes to Jira, so the only size limit is your Jira site's own. |
| `deleteAttachment` | Deletes an attachment by ID, permanently. Refused while a Jira project allowlist is set, because a bare attachment ID can't be checked against it. |
| `addComment` | Adds a comment to an issue. |
| `getComments` | Lists comments on an issue. |
| `addWorklog` | Logs time spent against an issue. |
| `listProjects` | Lists Jira projects, filterable by name or key. |
| `getProject` | Gets one project by key or ID. |
| `listIssueTypes` | Lists the issue types available in a project. |
| `listBoards` | Lists Agile boards, filterable by project or name. |
| `getBoard` | Gets one Agile board by ID. |
| `getBoardConfiguration` | Gets a board's filter and column configuration. |
| `listSprints` | Lists sprints on a board, optionally filtered by state. |
| `getSprint` | Gets one sprint by ID. |
| `moveIssuesToSprint` | Moves up to 50 issues into a sprint per call. |

**Confluence**

| Tool | What it does |
|---|---|
| `searchPages` | Searches pages with CQL, flat limit (25 by default, up to 100). |
| `getPage` | Gets a page by ID, optionally with its body. |
| `getPageByTitle` | Finds a page by exact title within a space. |
| `createPage` | Creates a page, plain text or storage-format XHTML body. |
| `updatePage` | Updates a page's title or body, versioning it automatically. |
| `getPageChildren` | Lists a page's direct children. |
| `addPageComment` | Adds a footer comment to a page. |
| `getPageComments` | Lists footer comments on a page. |
| `addPageLabels` | Adds one or more labels to a page. |
| `getPageLabels` | Lists labels on a page. |
| `listAttachments` | Lists a page's attachments (metadata only, no download). |
| `listSpaces` | Lists Confluence spaces, optionally filtered by key. |
| `getSpace` | Gets one space by key. |

Bodies accept plain text, which the worker converts, or a pre-built ADF (Jira) or storage-format XHTML (Confluence) body. A numeric Jira issue ID like `10042` is rejected by an allowlist until you resolve it to a key like `PROJ-123`.

## Set it up

1. Create an API token at [id.atlassian.com/manage-profile/security/api-tokens](https://id.atlassian.com/manage-profile/security/api-tokens).
2. In the Desktop app, open the project's integrations list and select **Atlassian**.
3. Enter your **Atlassian site URL** (`https://your-domain.atlassian.net`), your **Account email**, and the **API token**.
4. Optionally set the **Jira project keys** and **Confluence space keys** allowlists. Leave them blank to allow everything the account can reach.
5. Save.

<DesktopFrame screen="integrations" />

For the general steps to enable any integration and confirm it's working, see [Connect an integration](/docs/guides/connect-an-integration/).

When something fails, the worker maps the response to plain guidance: `401`/`403` means a wrong credential or missing permission, `404` means the item wasn't found, `429` means rate limited, `5xx` means Atlassian had a server error. Reads retry automatically; writes only retry on a 429, never a 5xx, so the worker never risks a duplicate issue or comment.

## Security boundaries

The worker runs as a non-root user with `cap_drop: ALL`, `no-new-privileges`, and a read-only filesystem, and both its mounts, the credential folder and the project folder at `/workspace`, are read-only too. An attachment path that escapes `/workspace` through `..` or a symlink is rejected, so the worker can't be talked into uploading its own token files. It can only reach the Atlassian Cloud site you gave it, and only as far as the allowlists permit once set. Redirects are disabled so the Authorization header can't leak to a different host, and any error message that would expose a credential is scrubbed before it reaches Claude. Claude and the Tool Gateway never see the site URL, email, or token. For how this isolation holds across every integration, see [How credentials are handled](/docs/security/credentials/).