> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aperium.apps.hillspire.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Confluence Data Center

> Connect Aperium to a self-hosted Confluence Data Center instance for page search, reads, and approval-gated writes with per-user tokens.

<Warning>
  **Experimental connector.** Confluence Data Center support is experimental. Behavior and the tool surface may change, and it is not yet on the same footing as the [Atlassian (Cloud)](/admins/integrations/supported/atlassian) connector. Pilot it before relying on it for production workflows.
</Warning>

The Confluence Data Center connector brings the Confluence half of the Atlassian tool surface to a **self-hosted** Confluence instance. It talks to the Confluence Data Center v1 REST API and authenticates with **per-user personal access tokens**, so every call carries the acting user's own Confluence permissions.

This is the Data Center counterpart to the cloud [Atlassian](/admins/integrations/supported/atlassian) connector — separate product, separate deployment, separate credentials. Jira Data Center is a sibling connector; see [Jira Data Center](/admins/integrations/supported/jira-dc).

## What you'll need

* A **Confluence Data Center 7.9 or later** instance reachable from your Aperium deployment.
* The instance's **base URL** (for example `https://wiki.example.com`), set once by an admin.
* A **personal access token** per user, created in Confluence under **Settings > Personal Access Tokens**.

## How auth works

Two stages, like other tenant-plus-personal integrations:

* **Admin** sets the tenant-wide **Confluence base URL** once.
* **Each user** pastes their own **personal access token**. Aperium renders it as a bearer token per request; plugin code never sees the raw token, and Data Center tokens do not refresh.

DC semantics apply throughout: spaces are addressed by key, users are keyed by username (no accountId), page bodies are storage-format XHTML (no ADF), and pagination is offset-based.

## Setup

<Steps>
  <Step title="Set the Confluence base URL (admin)">
    Open the **admin onboarding flow** or the **Admin Console's MCP Servers tab**, open the **Connect Confluence Data Center** form, and enter the root URL of your instance (for example `https://wiki.example.com`). Aperium probes `/rest/api/user/current` to confirm reachability.
  </Step>

  <Step title="Add a personal access token (each user)">
    On the **Integrations** page, each user creates a token in Confluence (avatar menu > Settings > Personal Access Tokens > Create token) and pastes it into Aperium. The token acts with that user's own Confluence permissions.
  </Step>

  <Step title="Verify">
    Ask an agent to find or summarize a recently updated page to confirm the connection works.
  </Step>
</Steps>

## What agents can do

**Reads.** Typed page and space searches (`search_confluence_dc_pages`, `search_confluence_dc_spaces`), raw CQL search, page reads, and an identity/who-am-I check.

**Writes — all approval-gated.** Five write tools, each requiring approval before it runs:

* **Create page.**
* **Update page** — the caller must pass the current version number (lost-update protection).
* **Deprecate (delete to trash)** — recoverable.
* **Purge page** — physical deletion; destructive, and floored to a tenant-admin capability.
* **Reply to comment.**

## Notes

* **Tokens don't refresh.** When a token is rejected, the user creates a new one under Settings > Personal Access Tokens in Confluence and re-enters it in Aperium.
* **Permissions follow the user.** Because every call uses the acting user's token, agents can only read and change what that user could in Confluence.
* **Disconnecting** removes a user's stored token; Confluence pages and spaces are unaffected.