--- title: "Atlassian Data Center" description: "The verified connector ai.oz0/atlassian-dc - Jira and Confluence Data Center from Atlassian's own OpenAPI documents, on your own application links, every write asking a person by default, Jira's webhooks as events." canonical_url: "https://docs.oz0.ai/build/plugins/verified/atlassian-dc" --- # Atlassian Data Center > The verified connector ai.oz0/atlassian-dc - Jira and Confluence Data Center from Atlassian's own OpenAPI documents, on your own application links, every write asking a person by default, Jira's webhooks as events. For: tenant administrators and plugin users. Connect Jira and Confluence Data Center with tools generated from Atlassian's OpenAPI documents and authenticated through your tenant's application links. Jira webhooks become events in Orchestrator Zero. An Orchestrator Zero connector for Jira and Confluence that a tenant runs itself. Atlassian's Rovo MCP server is for Atlassian Cloud only (use `atlassian` there), so this connector is our own: `oz0 plugin import openapi` wrote its two tools from the REST API documents Atlassian publishes, and `import.sh` writes them again.
Tool From Functions
atlassian_dc_jira Jira Software Data Center 11.3.12, https://developer.atlassian.com/server/jira/platform/jira_software_dc_11003_swagger.v3.json (sha256 1c2671f6...e92408 ) 27: 19 read, 8 write
atlassian_dc_confluence Confluence Data Center 11.0.0, https://dac-static.atlassian.com/server/confluence/11.0.0.swagger.v3.json (sha256 55ef3357...4c2498 ) 18: 15 read, 3 write
atlassian_dc_events Jira's webhook deliveries normalize
Read 2026-10-17, with [https://confluence.atlassian.com/adminjiraserver/jira-oauth-2-0-provider-api-1115659070.html](https://confluence.atlassian.com/adminjiraserver/jira-oauth-2-0-provider-api-1115659070.html) (OAuth 2.0 for incoming application links) and [https://confluence.atlassian.com/adminjiraserver/managing-webhooks-938846912.html](https://confluence.atlassian.com/adminjiraserver/managing-webhooks-938846912.html) (webhook secrets). ## Functions Each write asks a person by default through the plugin's suggested policy. An admin can switch that policy with a reason. - Jira writes: `create_issue`, `edit_issue`, `assign_issue`, `add_comment`, `update_comment`, `transition_issue`, `add_watcher` and `link_issues`. - Confluence writes: `create_content` (a page, blog post or comment), `update_content` and `add_labels`. - Jira reads: `search_issues` (JQL), `get_issue`, `get_comments`, `get_comment`, `get_transitions`, `get_issue_watchers`, `get_all_projects`, `get_project`, `get_create_issue_meta_project_issue_types`, `get_create_issue_meta_fields`, `get_edit_issue_meta`, `get_issue_link_types`, `get_myself`, `find_users`, `find_assignable_users`, `get_priorities`, `get_statuses`, `get_resolutions` and `get_server_info`. - Confluence reads: `search_content` (CQL), `search_site`, `list_content`, `get_content`, `list_children`, `list_comments`, `list_attachments`, `list_descendants`, `get_history`, `list_labels`, `list_watchers`, `list_spaces`, `get_space`, `list_space_content` and `get_current_user`. The rest of both APIs, about 400 operations including administration, is not imported. Each result is the HTTP status and Jira's or Confluence's answer as `{status, body}`. ## Connect it Each product is a connection of its own, `atlassian-dc-jira` and `atlassian-dc-confluence`, with the host it is served at. Two ways to sign in: An incoming application link (OAuth 2.0, the default). In Jira (or Confluence): Administration, Applications, Application links, Create link, External application, Incoming. Give it the redirect URL that `oz0 connection start atlassian-dc-jira` shows and the permission Write. Then: ```bash oz0 connection set atlassian-dc-jira --param host=jira.example.com --param client_id= oz0 connection start atlassian-dc-jira # paste the link's client secret, then sign in to Jira ``` The edge sends the client secret only to that host, keeps the token and refreshes it before it expires (Jira's last two hours, and each refresh replaces both tokens). Each call acts as the person who signed in. A personal access token (the fallback). Where an application link is not possible: ```bash oz0 connection set atlassian-dc-jira --param host=jira.example.com --param auth=token oz0 connection start atlassian-dc-jira # paste Jira's URL and a token of the account the connector acts as ``` The calls go only to the instance the connection was connected for; a changed host needs it connected again. On a private network. Before each call the node resolves the instance's host and connects only to the addresses it checked. An instance on the company's network (a private address, as most Data Center instances are) is reached only once the tenant's egress allowlist names it: ```bash oz0 tenant egress jira.example.com confluence.example.com ``` An address of the node itself, its link or a cloud's metadata service is never reached by name; only an allowlist entry that names the address reaches it. A change of the allowlist reaches the connector's running tools by itself: no restart is needed. Events. In Jira: System, WebHooks, Create a WebHook, with the URL `https:///events//atlassian-dc-jira`, the events you need (issue created, updated, deleted; comment created, updated, deleted) and a secret, which the tenant sets too, as a signing key bound to the edge's address: `oz0 secret set ATLASSIAN_DC_JIRA_WEBHOOK_SECRET --signing --host :7443`. The edge checks each delivery's `X-Hub-Signature` (`sha256=` and an HMAC-SHA256 of its body) before any node sees it. The events are `issue` and `comment`, with `created`, `updated` or `deleted`, and the issue's key as the subject. ## Develop ```bash uv lock && uv sync uv run pytest # the imported servers against a fake of Jira and Confluence, the events, the import OZ0_BIN=oz0 ./import.sh # write the tools again from Atlassian's documents (checked by their SHA-256) oz0 plugin pack . --list-tools # measure the listing again after a change, then oz0 plugin lint --verified . ``` ## Limits - Every write asks a person by default; an admin who switches a write to Allow takes on what follows. Jira and Confluence take no idempotency key: a retried `add_comment` comments twice, and a retried `create_issue` creates two issues. A transition made twice is one change. So no write says it honours a key, and the platform makes each write once. - A call over the instance's rate limit (HTTP 429) is not made again by the tool: the agent reads an error that says it is retryable and how long the instance asks to wait (its `Retry-After`). - The AI label: `add_comment`'s and `update_comment`'s text, the description `create_issue`, `edit_issue` and `transition_issue` set, and `create_content`'s and `update_content`'s body start with the tenant's label in brackets, such as `[AI agent]`, after the approval. Jira shows it as written in its wiki markup, Confluence as text before the page's first element. A description given as anything but text is refused, since it cannot carry the label.
The label goes in one place per function: an issue's summary (its title) and other fields an edit or a transition sets carry none, and the person who approves the call sees them as they will be posted.
`assign_issue`, `add_watcher`, `link_issues` and `add_labels` set a person, a link or label names, not text. With the tenant's label turned off, everything is posted as written. - The host: Jira and Confluence must be served at the root of their host (`https://jira.example.com/`). An instance at a context path (`https://example.com/jira`) works with a personal access token, whose URL is pasted whole, but not with the application link's sign-in. - Egress: the connector has no host of its own. Before each call the node resolves the connected instance's host and connects only to the addresses it checked. A public address is reached as it is; a private one (a company's own network) only once the tenant's egress allowlist names the instance (`oz0 tenant egress`); an address of the node itself, its link or a cloud's metadata service only when the allowlist names that address.
On a node with sandbox tier 1 its tools run in the node's sandbox, whose egress proxy reaches the instance once its host is on the tenant's egress allowlist. - Atlassian's documents describe answers loosely, so a result is not checked against them: it is the status and the body as Jira or Confluence sent it, up to 1 MiB. - Two functions are larger than a model's usual tool definition, as Atlassian's documents describe their bodies: `atlassian_dc_confluence.update_content` (about 1,800 tokens) and `atlassian_dc_jira.link_issues` (about 1,750). The plugin's 46 functions come to about 18,500 tokens; an agent lists only the functions it needs. - Atlassian's operation IDs are not names a model reads well (`search_1`, `update_2`), so `import.sh` names the functions; a POST that only reads (Jira's `POST /api/2/search`) is not imported, because a POST counts as a write. - Jira Service Management Data Center publishes an OpenAPI document of its own (11.3), not imported in this version: a service request is a Jira issue, which the Jira functions read and comment on. - No delegate agent: other plugins call the functions they were granted. - Webhooks: Jira Data Center sends no delivery ID, so a redelivery counts once only when its body is the same. Confluence's webhooks are not read. - Tested against a fake of Jira and Confluence Data Center, shaped from Atlassian's documents, not against a live instance. "Verified" means this project tested, pinned and secured the connector; Atlassian does not endorse it. ## Sitemap See the full [sitemap](https://docs.oz0.ai/sitemap.md) for all pages.