---
name: atlassian-confluence-oauth-app
description: The Confluence Cloud layer on top of the shared `atlassian-cloud-oauth` skill — the Confluence scope family and why a v2-era app ends up granular rather than classic, the v1/v2 REST split and what still only exists in v1, space/page/blogpost/attachment/comment addressing through `/ex/confluence/{cloudid}`, the space- and page-level permission model that makes a valid token see an empty wiki, data security policy app access rules, and Confluence's rate-limit budget. Use when asked to get Confluence OAuth credentials, register or scope a Confluence Cloud 3LO app, choose between `read:confluence-content.all` and `read:page:confluence`, or explain why a connected Confluence returns no pages. Read `atlassian-cloud-oauth` first for the console, callback, cloudid and refresh-token mechanics; use the Atlassian Jira skill for Jira, and note that Confluence Data Center is a different auth model entirely.
---

# Atlassian Confluence Cloud OAuth 2.0 (3LO) App Registration

Registering the app is the shared part. **What is specific to Confluence is that the scope decision and the API
generation decision are the same decision**, and that a perfectly scoped token can still come back with an empty
wiki because Confluence's permissions are per space and per page.

Confluence's v2 REST API is documented with **granular scopes only**, while the Confluence scope page still says to
prefer classic scopes where they are available. Both statements are true, and they point in opposite directions
unless you know which API generation you are calling. Getting that wrong produces a 401 that reads like a
permissions bug on an endpoint you are certain you are entitled to call.

## Built on: `atlassian-cloud-oauth`

**Read `atlassian-cloud-oauth` first, then this file.** It owns all the portal mechanics, and this file does not
repeat them:

- The Developer Console, creating an **OAuth 2.0 integration**, enabling 3LO, and the account that owns the app.
- **One callback URL per app**, and what that forces on a platform serving several data centers.
- Account-level vs resource-level grants, where the client ID and secret live, and the required `audience` and
  `prompt=consent` authorize parameters.
- The classic/granular scope model in general, `offline_access`, the under-50-scopes ceiling, and the rule that
  changing scopes re-consents every existing user.
- **Rotating refresh tokens** — 90-day inactivity expiry, 10-minute reuse leeway, and the failure that only appears
  on the *second* refresh.
- The **cloudid indirection**: `accessible-resources`, `/ex/{product}/{cloudid}/...`, and the array being multi-site
  under an account-level grant.
- Distribution, the unreviewed-app warning, Marketplace approval, and the two practices Atlassian names as
  non-compliant (collecting API tokens, or having customers create individual 3LO apps).

If you are reading only this file, you are missing all of the above.

## Inputs to collect before you start

The base skill lists the console inputs. These are the Confluence-specific ones:

| Input | Notes |
| --- | --- |
| **Which API generation will the client call — v1, v2, or both?** | This decides the scope family (§1, §2) |
| **Read-only, or create/update content?** | Write scopes are per resource in granular, product-wide in classic (§1) |
| **Which content types?** | Pages, blogposts, comments, attachments, whiteboards, databases, folders and custom content are **separate granular scopes** (§1) |
| **Is CQL search needed?** | Search has a classic scope and a granular equivalent — do not add both by reflex (§1) |
| **Do page restrictions matter?** | Restrictions are a v1-only API (§2, §4) |
| **Cloud or Data Center?** | Different auth model entirely — stop here if Data Center (§7) |
| **Expected call volume** | Confluence bills API traffic against an hourly point budget (§6) |

## Quick Start

1. Work the base skill's console steps, adding the **Confluence API** under Permissions (not the Jira API — they are
   separate scope lists on the same app).
2. Settle §2 first: which REST generation the client calls. It determines §1.
3. Add the scope family that generation documents, and keep it to one family (§1).
4. Confirm `offline_access` is in the set for anything that must survive the hour.
5. Confirm the client builds Confluence URLs as `/ex/confluence/{cloudid}/wiki/api/v2/...` — the `/wiki` segment is
   the one people drop (§3).
6. Before promising a customer anything about coverage, read §4: the authorizing user's space and page permissions
   are the real ceiling.
7. Finish the base skill's capture, round-trip and handoff steps, adding the Confluence checks in §8.

## Confluence platform state (verified 2026-09-20 — re-verify before trusting)

- **Two live REST generations.** v1 (`/wiki/rest/api/...`) and v2 (`/wiki/api/v2/...`) both have current reference
  documentation on developer.atlassian.com. v2's own introduction describes itself as *"the reference for the
  Confluence Cloud REST API v2, with definitions and performance intended to be an improvement over v1."*
- **v1 is being retired endpoint by endpoint, not all at once.** Individual v1 operations that have v2 equivalents
  carry their own deprecation notices and removal dates, and those dates have been extended more than once. As of
  this check the Confluence Cloud changelog carries **no blanket v1 removal entry**, and v1 groups with no v2
  equivalent — content restrictions, CQL search — are still the only way to do those things. Treat "v1 is gone" as
  false and "v1 is safe forever" as equally false: check the specific operation's page (§2).
- **v2 operation pages document granular scopes only.** Every v2 group checked — page, space, attachment, comment,
  content properties, space permissions — lists a single granular scope (`read:page:confluence`,
  `read:space:confluence`, `read:attachment:confluence`, `read:comment:confluence`) and no classic alternative.
- **v1 operation pages document both**, labelled *"Classic (RECOMMENDED)"* alongside the granular equivalent — for
  example content restrictions list classic `write:confluence-content` next to granular
  `read:content-details:confluence` and `write:content.restriction:confluence`.
- **The Confluence scope page still recommends classic**: *"Where available, the recommendation is to use classic
  scopes."* Read that as scoped to where classic scopes *are* available, which for v2-only endpoints is nowhere.
- **`search:confluence` is a classic scope**, not granular, despite its shape. Its granular equivalent for the CQL
  search endpoint is `read:content-details:confluence`.
- **Confluence rate limits are a points budget, not a request count** — a global pool by default, with a per-tenant
  pool available, `429` on exhaustion and `X-RateLimit-*` headers on the way there (§6).
- **Data security policy app access rules can silently hide content** from a correctly scoped app, per space, with a
  documented per-policy container limit (§5).

If the scope tables or the endpoint groups do not look like this, stop and report what you actually see.

## 1. The Confluence scope family

Confluence has its own classic list and its own granular list. Neither overlaps with Jira's.

**Classic** — broad, product-wide, and what v1 endpoints document:

| Scope | Covers |
| --- | --- |
| `read:confluence-content.all` | Read all content the user can see, including bodies |
| `read:confluence-content.summary` | Content summaries without bodies |
| `read:confluence-space.summary` | Space summaries |
| `read:confluence-content.permission` | Content restrictions and permission checks |
| `read:confluence-props` / `write:confluence-props` | Content and space properties |
| `read:confluence-user` | User details |
| `read:confluence-groups` / `write:confluence-groups` | Groups and membership |
| `search:confluence` | CQL search over content and space summaries |
| `write:confluence-content` | Create and update content |
| `write:confluence-space` | Create and update spaces |
| `write:confluence-file` | Upload attachments |
| `manage:confluence-configuration` | Confluence administration |
| `readonly:content.attachment:confluence` | Download attachments in read-only mode |

**Granular** — per resource, `verb:resource:confluence`, and what v2 endpoints document. The families that matter for
a content connector: `read:page:confluence`, `read:blogpost:confluence`, `read:space:confluence`,
`read:comment:confluence`, `read:attachment:confluence`, `read:folder:confluence`, `read:whiteboard:confluence`,
`read:database:confluence`, `read:embed:confluence`, `read:custom-content:confluence`,
`read:hierarchical-content:confluence` (ancestors, children, descendants), `read:content-details:confluence`
(details, properties, search), `read:content.metadata:confluence`, `read:space.permission:confluence`,
`read:configuration:confluence`, `read:user:confluence`, `read:group:confluence`, plus the `write:` and `delete:`
forms of each.

**Which generation to use now, and therefore which family:**

- **Calling v2 means granular.** There is no classic scope listed on a v2 operation page, so an app whose reads go
  through `/wiki/api/v2/...` needs the granular scopes and nothing the classic list offers will substitute. This is
  the case for any new Confluence content integration, because v2 is where pages, blogposts, whiteboards, databases,
  folders and the hierarchy endpoints live.
- **Calling v1 can use either**, and the pages mark classic as recommended. If the app *only* touches v1, classic is
  fewer scopes and less churn.
- **Calling both — the common case — is the trap.** Content restrictions and CQL search have no v2 equivalent (§2),
  so a v2-based app that also searches or reads restrictions lands in both families at once. Prefer resolving that
  with the **granular equivalent** the v1 page also lists — CQL search accepts `read:content-details:confluence`,
  which a v2 content app already holds — rather than bolting the classic scope onto a granular set. Adding
  `search:confluence` to an otherwise granular app is exactly the mixed-family shape the base skill warns about, and
  it is the first thing to check when search 401s with a scope message.
- **Granular is not free.** One content type per scope means a connector reading pages, blogposts, comments,
  attachments, folders, whiteboards, databases and the hierarchy is already eight or more scopes before users and
  groups. That is fine against the under-50 ceiling, but every one of them is a line on the consent screen and every
  addition later re-consents every customer. Decide the content-type list once.
- **Identity scopes are separate.** `read:me` and `read:account` come from the Atlassian account identity API, not
  the Confluence scope page, and a login-only authorization is its own set. Note that `ACCESS_EMAIL_ADDRESSES` is a
  **Connect-app scope**, not a 3LO one — if it appears in a 3LO authorize URL, check whether it is doing anything.

## 2. v1 and v2 — what only exists where

| Generation | Base path | Pagination | Scope family documented |
| --- | --- | --- | --- |
| v1 | `/wiki/rest/api/...` | `start` / `limit`, `_links.next` | Classic (recommended) **and** granular |
| v2 | `/wiki/api/v2/...` | Cursor — `limit` + `cursor`, `Link` header and `_links.next` | Granular only |

v2's pagination is cursor-based and Atlassian is explicit that you follow the link rather than compute an offset: the
next URL appears *"in both the `Link` header and under the `_links.next` property"*, and when there is no next page
neither is present. A client that pages by incrementing an offset against v2 will quietly under-read.

**Still v1 only, as of this check:**

- **Content restrictions** (`/wiki/rest/api/content/{id}/restriction`) — there is no v2 restrictions group. Any
  feature that reads or sets page-level restrictions is a v1 call.
- **CQL search** (`/wiki/rest/api/search`, and `/search/user`) — v2 has no search endpoint; filtering on the v2 list
  endpoints is not a substitute for CQL.

**Moved or reshaped in v2**, which is where migrations break:

- A **space is addressed by a numeric id** in v2, where v1 keyed spaces by their **space key**. The key still exists
  and is still what users see; it is no longer the path parameter. A client that stores the key as "the space id"
  works against v1 and 404s against v2.
- **Comments are split** into footer and inline, addressed under their parent
  (`/pages/{id}/footer-comments`, `/pages/{id}/inline-comments`, and `/blogposts/{id}/...`), with individual comments
  at `/footer-comments/{id}` and threaded replies at `/footer-comments/{id}/children`. A v1 client that treated
  "comments" as one list will silently miss half of them.
- Body formats are requested explicitly in v2 (`body-format`), and Atlassian has capped some listing endpoints at
  **50 results when `body-format` is included**, down from 250. A list that suddenly returns fewer rows than its
  `limit` asked for is usually this, not a permissions change.

**Before relying on any v1 call, open that operation's reference page and look for its own deprecation notice and
removal date.** Atlassian deprecates Confluence v1 per endpoint, and has repeatedly extended the dates, so neither a
blanket "v1 is fine" nor a blanket "v1 is dead" is checkable — only the specific operation is.

## 3. Addressing Confluence through the cloudid

The base skill covers `accessible-resources` and the `/ex/{product}/{cloudid}` form. Confluence's product segment is
`confluence`, and the part people get wrong is what follows it:

```
https://api.atlassian.com/ex/confluence/{cloudid}/wiki/api/v2/pages        # v2
https://api.atlassian.com/ex/confluence/{cloudid}/wiki/rest/api/search     # v1
```

Two specific traps:

- **`/wiki` is part of the path.** Atlassian's own 3LO example for Confluence shows a v1 call as
  `.../ex/confluence/{cloudid}/rest/api/space`, without it. Both forms circulate. Build against the path the API
  reference for your generation prints — v2 is documented as `/wiki/api/v2/...` throughout — and verify with one
  real call rather than reasoning about it.
- **One cloudid, several products.** A single Atlassian site commonly runs both Jira and Confluence, and the same
  cloudid addresses both; the product segment selects which. So a cloud-ID resolution path shared between connectors
  can produce a URL whose cloudid is right and whose product segment belongs to the other product. That failure
  presents as a 404 on every call, not as an auth error.

Content ids in v2 are numeric strings for pages, blogposts and spaces; attachment ids are opaque strings, and
attachments carry a `downloadLink` in the response rather than a constructible URL — follow it rather than building
one.

## 4. Permissions — the reason a valid token sees an empty wiki

Confluence authorization is a stack, and OAuth scopes are only the outermost layer. A 3LO token acts **as the
authorizing user**, so the app's effective access is the intersection of the granted scopes and that user's own
permissions:

1. **Global permission** — the user needs *"Permission to access the Confluence site ('Can use' global
   permission)"*, which is what the v2 list endpoints state as their requirement.
2. **Space permissions** — per space, per user or group. Getting a single space requires *"Permission to view the
   space."* A user who is not permitted in a space does not see it at all, and neither does the app.
3. **Page restrictions** — per page, and they narrow further within a space the user can otherwise read.

The operational consequence, and the thing to tell a customer before they open a support ticket: **listing endpoints
silently return only what the user can see.** Atlassian states it for pages — *"Only pages that the user has
permission to view will be returned"* — and the same shape holds elsewhere. There is no error, no partial-content
warning, and no way to distinguish "this space is empty" from "this user cannot see this space" from the response.

So:

- **"The connector isn't syncing our engineering space"** is far more often a space-permission problem than a scope
  problem, and re-registering the app fixes nothing. Check which account authorized, and what that account can see in
  the Confluence UI.
- **Who authorizes matters as much as what you ask for.** A connection made by a narrowly permissioned service user
  reads a narrow wiki, permanently and invisibly. If broad coverage is the product promise, say up front that the
  authorizing user must be able to see everything the customer expects to sync.
- **Page restrictions are only readable through v1** (§2). A connector that cannot see restrictions cannot explain
  its own gaps.

## 5. Data security policy app access rules

Confluence adds an admin-side block that sits outside scopes and consent entirely. An organization admin can attach
an **app access rule** to a data security policy, blocking apps from reading user-generated content in selected
spaces — Atlassian documents a limit of **15 containers (spaces) per policy**.

What that does to your app:

- It blocks **pages, blogposts and other user-generated content** in those spaces. Space key and name, audit records
  and templates remain readable, so the space still appears — with nothing in it.
- Blocked items *"will not appear in subsequent search or any other data retrieval results"*, and the app cannot
  update them. This is omission, not an error code.
- The signal is a response header, `Atlassian-DataSecurityPolicy: app_access_blocked`. A client that never looks at
  it cannot tell this apart from a permissions gap (§4) or an empty space.
- Reference pages mark each operation **exempt** or **not exempt** from app access rules, so you can tell in advance
  which of your calls can be blocked.

The asymmetry worth naming out loud: apps authenticating with **Atlassian API tokens or user credentials cannot be
blocked this way**. The compliant OAuth path is the blockable one. That is not an argument for the token path — the
base skill records that Atlassian names token collection as non-compliant — but it does explain why a customer's
admin may see different behavior from two integrations.

## 6. Rate limits

Confluence Cloud meters API traffic as an **hourly points budget**, not a request count, and the budget depends on
which pool the app is in:

- **Global pool (the default)** — the app shares *"a single 65,000 point hourly quota across all tenants."* For a
  multi-tenant connector that is the number that matters, and it is shared across every customer.
- **Per-tenant pool** — a larger, per-customer budget that scales with the customer's edition and user count, capped
  well above the global figure.

When the budget is exhausted the API returns **`429 Too Many Requests`** with `Retry-After`, and there is *"no
partial throttling"* — further requests are denied until the window resets. On the way there, `X-RateLimit-Limit`,
`X-RateLimit-Remaining`, `X-RateLimit-Reset` and `X-RateLimit-NearLimit` (true below 20% remaining) let a client back
off before it is cut off, and `RateLimit-Reason` says which pool was breached.

Two consequences for a connector: a 429 is **not** an authorization problem and must never trigger a re-authorization
or a token refresh; and a full-wiki initial sync on the shared global pool is the most likely way one customer
degrades every other customer's connection. Confirm which pool the app is in before promising a sync window.

## 7. Confluence Data Center is not this

**Confluence Data Center / Server does not use any of this.** No Atlassian-hosted developer console, no
`auth.atlassian.com`, no cloudid, no `/ex/confluence/...`. Authentication is against the customer's own instance —
personal access tokens, or basic auth, with Confluence Data Center separately able to act as an **OAuth 2.0
provider** for its own integrations. The REST API is the Data Center reference, not the Cloud one, and the endpoint
paths differ.

If the customer's URL is not `*.atlassian.net` or a custom Atlassian Cloud domain, stop: nothing in this file or the
base skill applies, and a Cloud client ID will never authenticate against it.

## Product fact — what the Confluence connector asks for

> **As of 2026-09-20, Unified.to's Confluence connector requests:** a **granular** Confluence scope set, narrowed per
> unified object and per read direction rather than one flat union, with `read:me` and `offline_access` in every
> data-object set. Reading pages pulls the widest set — page, folder, attachment, hierarchical-content, database,
> whiteboard, content, embed and content-details granular scopes — **plus the classic `search:confluence`**, which is
> the one classic scope in an otherwise granular app. That is the mixed-family shape §1 warns about, and it may be
> removable: the CQL search endpoint also accepts the granular `read:content-details:confluence`, which this set
> already contains. Spaces, comments, users and groups each request their own narrow granular read scope. The
> identity / login authorization is different again — Atlassian account identity scopes plus an email-address scope
> that Atlassian documents as a **Connect-app** scope rather than a 3LO one, and **no `offline_access`**, so that
> flow gets no refresh token by design.
>
> Two things beyond scopes. The connector expects an **Atlassian organization admin API key** alongside the OAuth
> credentials, and it offers a **non-OAuth path** — Confluence site URL plus account email plus an Atlassian API
> token. Collecting API tokens is exactly the pattern Atlassian's 3LO pages name as non-compliant (see the base
> skill), so raise it rather than registering around it.
>
> On the API side the connector's page reads currently go through the **v1** CQL search and v1 content endpoints
> rather than v2, with the v2 equivalents present but disabled. That makes §2's per-endpoint v1 deprecation exposure
> a live concern rather than a theoretical one, and it is the likeliest reason the classic search scope is in the set
> at all. It pages with `limit` and a next link, with a maximum page size of 250 for content objects and a smaller
> one for users and groups — note §2's 50-result cap when a body format is requested, which a 250 limit will not
> override.
>
> This note is dated, not live. **Confirm all of it with the connector's owner before registering anything** — the
> connector, not this document, is the source of truth for what it sends.

## 8. Confluence-specific end-to-end checks

On top of the base skill's authorize → accessible-resources → refresh round trip:

1. Make one real read against `https://api.atlassian.com/ex/confluence/{cloudid}/wiki/api/v2/pages` and confirm the
   `/wiki` segment and the product segment are both right (§3).
2. **Page it.** Follow `_links.next` or the `Link` header at least twice, and confirm the client is not incrementing
   an offset against v2 (§2).
3. Authorize as a **restricted user** — someone who cannot see one known space — and confirm the connector reports
   the gap rather than reporting success on a partial wiki (§4).
4. If search is in scope, call the CQL search endpoint and confirm which scope actually satisfies it before shipping
   a mixed-family scope set (§1).
5. Read a page that carries **page restrictions** and confirm the client's behavior is deliberate (§4).
6. Check the response headers on a content read for `Atlassian-DataSecurityPolicy` (§5), and log it — this is the
   only distinguishable signal for an admin-blocked space.
7. Watch `X-RateLimit-Remaining` during an initial sync (§6).

| Symptom | Cause |
| --- | --- |
| 401 with a scope message on search, everything else fine | Classic `search:confluence` vs granular family mismatch — try `read:content-details:confluence` (§1) |
| 404 on every Confluence call, auth fine | `/wiki` missing from the path, or the wrong product segment on a shared cloudid (§3) |
| 404 addressing a space that exists | v2 wants the numeric space id; the space **key** is a v1 concept (§2) |
| Connected successfully, zero pages returned | The authorizing user cannot see those spaces (§4) |
| One space appears but is always empty | Space permissions (§4), or a data security policy app access rule (§5) |
| Half the comments are missing | Only footer or only inline comments are being read (§2) |
| Lists return 50 rows when 250 were requested | A body format was requested on a listing endpoint (§2) |
| Sync silently stops partway | Cursor pagination not followed — offset paging against v2 (§2) |
| `429` mid-sync | Hourly points budget exhausted; back off, do **not** re-authorize (§6) |
| A v1 call that worked last quarter now 404s | That operation's own deprecation window closed (§2) |
| Nothing resembles this; the site is not `*.atlassian.net` | Confluence Data Center — different auth model entirely (§7) |

## Stop and ask

Beyond the base skill's list, hand back to a human when:

- The client calls **both v1 and v2** and nobody has decided how to keep the scope set in one family (§1, §2).
- A feature depends on **content restrictions or CQL search**, both v1-only, and the v1 deprecation exposure has not
  been assessed (§2).
- Coverage has been promised that depends on **who authorizes** — broad-wiki sync via a narrowly permissioned
  service account cannot be fixed in the console (§4).
- A customer's admin has applied a **data security policy app access rule** and someone proposes switching to
  Atlassian API tokens to get around it (§5).
- The expected volume does not fit the **global points pool** and nobody owns the per-tenant pool question (§6).
- The target turns out to be **Confluence Data Center** (§7).
- Anyone asks to add or remove a Confluence scope on a live app — that re-consents every connected customer.
- The scope tables or endpoint groups do not match the **Confluence platform state** section above.

## References

Confluence-specific only; the base skill carries the portal-wide Atlassian references. Every link verified to
resolve on 2026-09-20.

- OAuth 2.0 (3LO) apps — Confluence Cloud — https://developer.atlassian.com/cloud/confluence/oauth-2-3lo-apps/
- Confluence scopes for OAuth 2.0 (3LO) and Forge apps (classic and granular) — https://developer.atlassian.com/cloud/confluence/scopes-for-oauth-2-3LO-and-forge-apps/
- Confluence Cloud REST API v2 intro (cursor pagination, base path) — https://developer.atlassian.com/cloud/confluence/rest/v2/intro/
- Confluence Cloud REST API v1 intro — https://developer.atlassian.com/cloud/confluence/rest/v1/intro/
- v2 Page endpoints (scopes, permission statements) — https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-page/
- v2 Space endpoints (numeric space id) — https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-space/
- v2 Blog post endpoints — https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-blog-post/
- v2 Comment endpoints (footer vs inline) — https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-comment/
- v2 Attachment endpoints (`downloadLink`) — https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-attachment/
- v2 Space permission endpoints — https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-space-permissions/
- v1 Content restrictions (no v2 equivalent) — https://developer.atlassian.com/cloud/confluence/rest/v1/api-group-content-restrictions/
- Security for Confluence Cloud apps (scopes intersected with user permissions) — https://developer.atlassian.com/cloud/confluence/security-overview/
- Data security policy developer guide (app access rules, blocked-content header) — https://developer.atlassian.com/cloud/confluence/data-security-policy-developer-guide/
- Confluence Cloud rate limiting (points pools, headers) — https://developer.atlassian.com/cloud/confluence/rate-limiting/
- Confluence Cloud changelog — https://developer.atlassian.com/cloud/confluence/changelog/
- Using the Confluence REST API — https://developer.atlassian.com/cloud/confluence/using-the-rest-api/
- Basic auth for REST APIs (the API-token path) — https://developer.atlassian.com/cloud/confluence/basic-auth-for-rest-apis/
- Deprecation notice — basic authentication with passwords — https://developer.atlassian.com/cloud/confluence/deprecation-notice-basic-auth/
- Confluence Data Center REST API (*not* this skill) — https://developer.atlassian.com/server/confluence/confluence-server-rest-api/
- Confluence Data Center OAuth 2.0 provider API (*not* this skill) — https://developer.atlassian.com/server/confluence/confluence-oauth2-provider-api/
- Confluence Cloud free signup — https://www.atlassian.com/try/cloud/signup?bundle=confluence