Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/cloudflare/cloudflare-os/llms.txt

Use this file to discover all available pages before exploring further.

The Confluence Gatekeeper connects Cloudflare OS to Atlassian Cloud Confluence via OAuth 2.0 (three-legged OAuth, or 3LO), giving agents and Gadgets the ability to search spaces, read and write pages and blog posts, manage comments and labels, and handle attachments. Page and blog post bodies are automatically converted to and from Markdown so agents can work with content naturally without dealing with Confluence’s native storage format.
Only Atlassian Cloud (*.atlassian.net) is supported. Confluence Server and Confluence Data Center are not supported — there is no on-premises adapter.

​
Resource Granularities

Access is granted at one of three granularities. You can introduce an agent to an entire Confluence site, a single space, or a specific page or blog post — each yields a different session type with an appropriately scoped API.
GranularityURL patternSession type
Site — search and open any space, page, or blog post the account can accesshttps://*.atlassian.net/wikiConfluenceSite
Space — list, search, and create pages and blog posts within one spacehttps://*.atlassian.net/wiki/spaces/:spaceKeyConfluenceSpace
Page or blog post — read/edit the body, manage labels/comments/attachments, create child pageshttps://*.atlassian.net/wiki/spaces/:spaceKey/pages/:pageId/*ConfluenceContent
A single account-level OAuth grant can span multiple Confluence sites. When you paste a resource URL from any of your accessible Confluence sites, the gatekeeper resolves the host to the correct cloud ID automatically.

​
Setting Up Atlassian OAuth 2.0

1

Create an OAuth 2.0 integration

  1. Go to the Atlassian Developer Console.
  2. Click Create and choose OAuth 2.0 integration.
  3. Give it a name (e.g., “My Company OS”) and click Create.
2

Add the Confluence API and enable scopes

In the integration, go to Permissions → Add APIs and add Confluence API.You must enable scopes from both the Granular scopes tab and the Classic scopes tab. The gatekeeper uses the v2 API for most operations (requiring granular scopes) and falls back to v1 endpoints for a few capabilities (requiring classic scopes).Granular scopes (for the v2 REST API):
read:space:confluence
read:page:confluence
write:page:confluence
delete:page:confluence
read:blogpost:confluence
write:blogpost:confluence
delete:blogpost:confluence
read:comment:confluence
write:comment:confluence
delete:comment:confluence
read:label:confluence
write:label:confluence
read:attachment:confluence
write:attachment:confluence
delete:attachment:confluence
read:user:confluence
Classic scopes (for v1 fallback endpoints — CQL search, label writes, attachment upload, restore):
search:confluence
read:confluence-content.all
read:confluence-content.summary
read:confluence-space.summary
write:confluence-content
write:confluence-file
readonly:content.attachment:confluence
read:confluence-user
Account-level scopes (always required):
read:me
offline_access
3

Set the authorization callback URL

In the integration, go to Authorization and set the callback URL:
  • Local dev: http://localhost:8787/gatekeeper/confluence/oauth
  • Production: ${PUBLIC_BASE_URL}/gatekeeper/confluence/oauth
4

Copy your credentials

Go to Settings in the integration and copy the Client ID and Secret.
5

Configure credentials

For local development, set the credentials in the repo-root .dev.vars:
.dev.vars
CONFLUENCE_CLIENT_ID=your-client-id
CONFLUENCE_CLIENT_SECRET=your-client-secret
The dev server maps CONFLUENCE_CLIENT_ID / CONFLUENCE_CLIENT_SECRET into the Worker’s CLIENT_ID / CLIENT_SECRET automatically. For production, set CLIENT_ID and CLIENT_SECRET as secrets on the deployed Worker and set BASE_URL to the public gatekeeper URL.

​
Markdown Conversion

Page and blog post bodies are exchanged as Markdown. The gatekeeper converts between Confluence’s native “storage format” (XHTML with custom macros) and Markdown automatically, so agents can read and write page content without dealing with XML.
  • Reading: Confluence storage format is converted to Markdown before being returned to the agent
  • Writing: Markdown from the agent is converted back to Confluence storage format before being saved
  • Unsupported macros: degrade gracefully to a labeled placeholder rather than failing

​
What Agents Can Do

Once a Confluence resource is introduced, agents can:
  • listSpaces — list all accessible spaces
  • getSpace — fetch a space’s metadata
  • getContent — fetch a page or blog post by ID
  • search — full-text search or raw CQL query across the entire site
  • getCurrentUser — read the connected user’s identity

​
Approvals and Simulation

Every read operation is recorded as an observation. Every write — creating or editing a page, posting a comment, adding a label, uploading an attachment — is staged in the approval queue and not sent to Confluence until you approve it. While writes are pending approval, the agent sees simulated results: provisional IDs for created content, body overlays for edited pages, trashed-state tracking. This means the agent can continue building on the results of a pending write without being blocked by the approval step.

​
Notes and Limitations

  • The author and lastUpdatedBy fields expose only an accountId. The Confluence v2 API returns IDs rather than full user objects.
  • CQL search, label add/remove, attachment upload, and restore-from-trash rely on v1 API endpoints. If Atlassian removes these endpoints, those operations will surface a clear “not available” error rather than failing silently.
  • Attachment downloads are capped at 16 KB.

Build docs developers (and LLMs) love

Get started for freeTalk to us