Skip to main content
Confluence is Atlassian’s team workspace and wiki, where teams create, organize and share pages, blog posts and documents in spaces. This connector reads your Confluence Cloud site through the official REST API and brings your spaces, pages and blog posts with their content and version, footer and inline comments, attachment details, labels, page edit history, tasks, users and groups.
The connector only reads data. It never creates, changes or deletes anything in Confluence. It sees exactly what the Atlassian account you connect can see: spaces and pages that account cannot view are not synced.

Configuring Confluence as a Source

In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Confluence option from the list of connectors. Click Next and you’ll be prompted to add your access.

1. Add account access

The connector signs in with the e-mail of an Atlassian account and an API token of that account. To create the token, sign in to id.atlassian.com with that account, open Security > API tokens, click Create API token, give it a name (for example, “Nekt”) and an expiration date, and copy the token when it is shown. See Atlassian’s guide for details.
Use an account that can view every space you want to sync (a dedicated account for integrations works well). The data in Nekt follows that account’s permissions in Confluence.
The following configurations are available:
  • Confluence Site URL: The address of your Confluence Cloud site, as shown in the browser, for example https://your-company.atlassian.net.
  • E-mail: The e-mail of the Atlassian account that created the API token.
  • API Token: The API token. A regular token (Create API token) works as is. A token created with Create API token with scopes needs the read scopes of the tables you select (see Permissions and scopes).
  • Body Format (advanced, optional): The format of the content of pages, blog posts, comments and tasks. storage (default) is Confluence’s XHTML; atlas_doc_format is the Atlassian Document Format (JSON); none syncs only the metadata, without the content, which makes syncs faster. When empty, storage is used.
Once you’re done, click Next.

2. Select streams

Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis.
Tip: The stream can be found more easily by typing its name.
Select the streams and click Next.

3. Configure data streams

Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.
  • Layer: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
  • Folder: a folder can be created inside the selected layer to group all tables being created from this new data source.
  • Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
  • Sync Type: you can choose between INCREMENTAL and FULL_TABLE.
    • Incremental: every time the extraction happens, we’ll get only the new data, which is good if, for example, you want to keep every record ever fetched.
    • Full table: every time the extraction happens, we’ll get the current state of the data, which is good if, for example, you don’t want to have deleted data in your catalog.
Once you are done configuring, click Next.

4. Configure data source

Describe your data source for easy identification within your organization, not exceeding 140 characters. To define your Trigger, consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times). Optionally, you can define some additional settings:
  • Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
  • Determine when to execute an Additional Full Sync. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while. For Confluence it keeps the Pages, Blog Posts and Attachments tables in line with content moved to the trash, archived, moved or permanently deleted (see Implementation notes).
When you are ready, click Next to finalize the setup.

5. Check your new source

You can view your new source on the Sources page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.
For you to be able to see it on your Catalog, you need at least one successful source run.
Page Versions and Content Labels are not selected by default because they make many requests: Page Versions asks for the history of every page on the first sync (and, after that, only of the pages edited since the last sync), and Content Labels asks three lists per label on every sync. Select them only if you need them.

Permissions and scopes

The connector reads what the connected account can view. A table the account cannot read is skipped with a warning in the sync log naming the table and what is missing, and the other tables keep syncing; the sync fails only when none of the selected tables can be read or the e-mail and API token are rejected. If you use a token with scopes, give it these read scopes (only those of the tables you select):

Fields by stream

Content

Spaces the account can view, current and archived.Table: spaces · Primary key: id · Sync: Full table
Pages with their current content and version, including archived pages and pages in the trash.Table: pages · Primary key: id · Sync: Incremental on last_modified_at
Blog posts with their current content and version, including posts in the trash.Table: blog_posts · Primary key: id · Sync: Incremental on last_modified_at
Where every page, blog post and attachment is now: its status, space, parent, position and owner, without the content. Read in full on every sync, so it always reflects pages moved to the trash, archived, moved in the page tree or given to another owner, which the incremental tables only see when the content is edited again. Join it with Pages, Blog Posts or Attachments on content_type and id.Table: content_metadata · Primary key: content_type, id · Sync: Full table
Edit history: one row per saved version of every page (who saved it, when and with which message; not the content of old versions). Not selected by default.Table: page_versions · Primary key: page_id, version_number · Sync: Incremental on created_at
Action items (checkbox tasks) written in pages and blog posts.Table: tasks · Primary key: id · Sync: Full table

Comments and attachments

Comments attached to highlighted text of pages and blog posts, with their resolution status.Table: inline_comments · Primary key: id · Sync: Full table
Details of the files attached to pages and blog posts (the files themselves are not downloaded).Table: attachments · Primary key: id · Sync: Incremental on last_modified_at

Labels

Labels (tags) used on the site.Table: labels · Primary key: id · Sync: Full table
Which label is on which page, blog post or attachment: one row per label and content. Not selected by default.Table: content_labels · Primary key: label_id, content_type, content_id · Sync: Full table

People

Users of the site (licensed users and guests).Table: users · Primary key: account_id · Sync: Full table
User groups of the site.Table: groups · Primary key: id · Sync: Full table
Who is in each group: one row per group and user.Table: group_members · Primary key: group_id, account_id · Sync: Full table

Implementation notes

  • Incremental tables. Pages, blog posts, footer comments and attachments are read in full on the first sync (and on full syncs). After that, each sync reads only what changed since the previous one (re-reading the last hour), based on the date of the last edit.
  • Content. The body column holds the content in the format chosen in Body Format, as text. Confluence’s XHTML (storage) keeps macros and formatting; to analyze plain text, strip the tags in a Query or Notebook.
  • Inline comments, tasks, labels, users and groups are read in full on every sync: resolving an inline comment, adding a label, or completing a task does not change anything Confluence lets the connector filter by.
  • Trash, archive, moves and owners. Moving content to the trash, archiving it, moving a page in the page tree or changing its owner does not create a new version in Confluence, so the incremental tables (Pages, Blog Posts, Attachments) keep the previous status, parent and owner until the content is edited again. Use the Content Metadata table, read in full on every sync, for the current values, or schedule an Additional Full Sync (for example weekly) to refresh the incremental tables. Content permanently deleted from the trash leaves Content Metadata on the next sync and stays in the incremental tables until a full sync.
  • Users. Confluence lists at most 10,000 users through its API; the sync log warns when a site reaches that limit. E-mails are often empty because of the users’ privacy settings.
  • Safety. Full-table streams are read completely before anything is written to Nekt, so a sync that fails halfway does not replace them with partial data; if one that had records comes back empty (for example, after the account lost access), that table fails instead of being emptied; run a full sync of the source if the data really was removed. Incremental tables are written as they are read and only move their sync position forward when the read is complete, so a failed sync is read again on the next one.
  • Speed. Requests are sent one at a time and the connector waits when Confluence asks it to slow down, which the sync log shows. Choosing none in Body Format makes syncs much lighter when you only need metadata.

Troubleshooting