Confluence Cloud Port

Purpose

This is the Harbor reference integration for the Confluence Cloud REST API.

Use it when:

• building Confluence Cloud actions in Harbor
• extending the Dock / Hub Confluence Cloud entry
• teaching Codex or OpenClaw how to map a knowledge-base API into Harbor Ports and Harbor Actions without turning Harbor into a generic wiki admin proxy

Harbor Port worksheet

Product

• Product: Confluence Cloud REST API
• Publisher slug: atlassian
• Publisher name: Atlassian
• Category: Knowledge Base
• Tags: confluence, atlassian, wiki, pages, documentation

Safe Harbor Port metadata

• Kind: http_api
• Label: Confluence Cloud API
• Description: Confluence Cloud API connection managed locally through Harbor.
• Base URL: https://your-domain.atlassian.net/
• Auth mode: header_token
• Auth header name: Authorization
• Auth token prefix: Bearer

Hidden local config

• authToken
• local tenant base URL override

Harbor stores the token locally only. Dock / Hub manifests must never contain it.

Harbor action design notes

Confluence Cloud is a good Harbor fit when we keep page discovery bounded, page lookup explicit, and page creation reviewable.

Good Harbor Confluence starter actions:

• bounded GET page listing with typed filters for title, space, status, and pagination
• explicit single-page lookup by page ID
• one reviewable POST route for page creation
• requestBodyMode: "none" for reads
• requestBodyMode: "json" for the bounded create request body
• resultMode: "json_summary" for all starter actions

Avoid for now:

• broad Confluence admin and permission-management surfaces
• arbitrary CQL or generic content-search passthroughs
• page update, delete, and bulk content mutation actions before policy review
• generic route forwarding across the Confluence API

Starter Confluence actions

Automatic read actions

• search-pages -> GET /wiki/api/v2/pages
• get-page -> GET /wiki/api/v2/pages/{id}

Approval-friendly write actions

• create-page -> POST /wiki/api/v2/pages

Why these actions

These routes fit Harbor's current safe model because they:

• stay under one tenant-owned Confluence Cloud origin that the operator configures locally
• use explicit page identifiers or typed filter inputs instead of arbitrary path editing
• give agents a useful documentation workflow without exposing broad space-administration capabilities
• keep page creation as a named, reviewable action instead of generic authenticated HTTP access

Action Model notes

For Confluence actions, Harbor stores explicit route templates and typed parameter metadata such as:

• /wiki/api/v2/pages
• /wiki/api/v2/pages/{id}

At execution time, callers supply values by location:

• input.query for page filters and pagination
• input.path.id for single-page lookup
• input.body for JSON page creation payloads

Example page search request:

{
  "query": {
    "space-id": "123456",
    "title": "Harbor rollout",
    "status": "current",
    "limit": 25
  }
}

Example page lookup request:

{
  "path": {
    "id": "123456789"
  },
  "query": {
    "body-format": "storage",
    "include-labels": true
  }
}

Example create request:

{
  "body": {
    "spaceId": "123456",
    "status": "current",
    "title": "Harbor rollout checklist",
    "body": {
      "representation": "storage",
      "value": "<p>Opened from Harbor after operator review.</p>"
    }
  }
}

Harbor fills path placeholders safely, validates query values against stored schema, and keeps the request origin Harbor-owned.

Tenant configuration note

Confluence Cloud is tenant-scoped. After importing from Dock / Hub, the operator must replace the placeholder base URL with the actual site URL, such as https://acme.atlassian.net/, before any action will work.

Safety note for page creation

create-page stays on require_approval because Confluence writes can notify watchers, alter shared documentation, and trigger downstream knowledge workflows. Harbor should treat that as an explicit, reviewable capability.

Suggested operator workflow

1. Import the Confluence Cloud Dock entry from Dock / Hub.
2. Replace the placeholder base URL with your Confluence Cloud tenant URL.
3. Configure the local Confluence bearer token in Harbor Node with the scopes you need.
4. Use search-pages first to confirm the port is working.
5. Use get-page to inspect a known page before adding write flows.
6. Keep create-page on require_approval unless there is a very deliberate local policy reason not to.

Suggested agent workflow

1. Inspect the existing Confluence Harbor Port.
2. Inspect live actions and drafts.
3. Propose additional fixed or tightly bounded Confluence routes only.
4. Validate and test drafts.
5. Request publish instead of self-publishing unless Harbor explicitly allows it.

Agents should never:

• ask Harbor for the stored Confluence token
• edit hidden auth directly
• widen Confluence into a generic tenant-wide admin proxy
• hide tenant-specific targeting behind arbitrary URL input

Current update strategy

For now, Confluence Cloud updates are manual:

• update the Dock / Hub Confluence integration document in apps/hub/catalog/integrations/atlassian/confluence-cloud-api.json
• bump the manifest version when the action set changes materially
• re-import into Harbor or create new drafts from the updated Dock entry

Future expansions such as page updates, comments, and attachments are intentionally deferred until Harbor has clearer policy controls for mutation-heavy documentation tooling.

Official reference starting points

• Confluence REST API v2 overview: https://developer.atlassian.com/cloud/confluence/rest/v2/intro/
• Page API: https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-page/
• Confluence OAuth scopes: https://developer.atlassian.com/cloud/confluence/scopes-for-oauth-2-3LO-and-forge-apps/