Skip to main content

​
Part 1: Jira and Confluence Data Ingestion

Set up an Atlassian API token so ConfigView can pull your Jira users, groups and group membership, application-role seat usage, global administrative settings, the apps installed in Jira and Confluence, your Confluence spaces and who can see them, the Confluence audit log, and (optionally) your organization’s API tokens and organization audit log into the dashboard. Jira and Confluence live on the same Atlassian site and share one user directory, so one token covers both. There is no separate Confluence app to connect: the Confluence collectors are part of the Jira app. This integration uses the Jira Cloud REST API v3 for users, groups, roles, and settings; the Confluence Cloud REST API (v2 for spaces and space permissions, v1 for the audit log); the Universal Plugin Manager for installed apps; plus the Atlassian organization Admin API for the optional API-token audit and organization audit log.
ConfigView only reads. It never reads page or issue content, and never changes a setting, permission or app.

​
Step 1: Create a Jira API Token

  1. Go to: https://id.atlassian.com/manage-profile/security/api-tokens
  2. Click Create API token
  3. Label: ConfigView
  4. Click Create
  5. Copy the token — you will only see it once
The token inherits the permissions of the user that created it. For the full data set, create it under an account that is a Jira administrator and has the Confluence Administrator global permission (Confluence → Settings → Global permissions). A non-admin token can still read the user directory and the Confluence spaces it can see. API tokens expire (one year at most for tokens created today). When one expires every Jira and Confluence collector stops at once, and the health check’s Jira API auth row says so. Put the expiry date in a calendar.

​
Step 2: Add the Credentials to ConfigView

ConfigView authenticates to Jira with HTTP Basic auth: your Atlassian account email plus the API token, against your site URL.
  1. Go to your ConfigView dashboard: https://{companyname}.configview.com/admin/integrations/jira
  2. Under Credentials, enter each value and click the save icon on its row:

​
Step 3: (Optional) Enable the API-Token Audit and Organization Audit Log

The API Tokens script lists every user API token across your Atlassian organization — token label, owner, creation date, last-active date, and expiry — so you can find stale or never-expiring tokens. The Organization Audit Log script reads the organization-wide audit log: sign-ins, group and product-access changes, policy changes and token creation across Jira, Confluence and Atlassian Administration. Both use the org-level Admin API, which needs two extra secrets and an organization admin API key. The organization audit log also needs Atlassian Guard (formerly Atlassian Access) or an Enterprise plan.
  1. Find your organization ID: go to https://admin.atlassian.com, select your organization — the id is in the URL (/o/{orgId}/...).
  2. Create an organization API key (admin.atlassian.com → Settings → API keys → Create API key). If you are asked for scopes, grant read:tokens:admin (API tokens), read:directories:admin (organization admins) and read:events:admin (organization audit log).
  3. Add these secrets at https://{companyname}.configview.com/admin/integrations/jira:
If you skip this step, the API Tokens and Organization Audit Log scripts still run — they record nothing, with a note explaining the secrets are not set. Every other script is unaffected.

​
Step 4: Enable the Jira App in ConfigView

  1. Go to: https://{companyname}.configview.com/admin/integrations/jira
  2. Click Connect. ConfigView creates its tables and schedules every collector at your default run time.
  3. The collectors it will start running — stop any you do not want under Collectors:
    • Users — Every Atlassian account visible to the token (active, inactive, app, and customer accounts)
    • Groups — All groups on the site (id + name)
    • Group Members — One row per group × member, with each member’s active flag (run alongside Groups)
    • Application Roles — Seat and license usage per application role (defined seats, used seats, remaining seats)
    • Settings — Global administrative settings: feature flags from /configuration plus advanced application-properties (properties need a Jira admin token)
    • API Tokens — Organization-wide user API token inventory for stale/expired-token audit (needs the Step 3 secrets)
    • Installed Apps (Jira + Confluence) — Apps installed in each product: name, vendor, version, enabled, and whether the customer installed it (needs a site admin)
    • Organization Admins — Who holds organization admin, site admin, user access admin and product admin roles, and on which site or product (needs the Step 3 secrets)
    • Organization Audit Log — Atlassian organization audit log (needs the Step 3 secrets and Atlassian Guard or Enterprise)
    • Confluence Spaces — Every space the token can see: key, name, type, status, creator
    • Confluence Space Permissions — Who can do what in each space, including anonymous and guest access (run alongside Confluence Spaces)
    • Confluence Audit Log — Permission changes, exports, group changes, app installs (needs the Confluence Administrator permission)
  4. Click Verify now to confirm the credentials work.
Permission note: Users works with any token. Groups, Group Members, Application Roles, and the application-properties half of Settings call admin endpoints that Jira gates behind administrator permission. Confluence Audit Log needs the Confluence Administrator global permission, and Confluence Spaces only returns spaces the token’s account can view - so an account without admin rights misses restricted and other people’s personal spaces. When a capability isn’t granted, the script records an empty (or partial) snapshot with an explanatory note instead of failing — so it’s safe to enable them on any token. A site without Confluence is fine too: the Confluence scripts record nothing.

​
Step 5: Verify

  1. Go to: https://{companyname}.configview.com/admin/status/
  2. Run the Jira health check
  3. The core checks should pass:
    • Secret Manager access (JIRA_BASE_URL / JIRA_EMAIL / JIRA_API_TOKEN)
    • Jira API auth (/myself)
    • /users/search endpoint reachable
    The optional capability checks — Groups, Application roles, Settings, API tokens, Confluence audit log, Installed apps (one row per product) and Org audit log — report ok when reachable, or skip with a permission/scope note when your token doesn’t grant them. A skip is expected for non-admin tokens (or when the Step 3 secrets aren’t set) and does not fail the overall health check. Confluence spaces must pass if your site has Confluence; it reports skip when the site has none. The Confluence audit log row also shows how long your site keeps audit history. If Jira API auth fails with AUTH FAILED (HTTP 401), the token is expired or revoked: every other check is skipped and every collector is failing. Create a new token (Step 1) and replace JIRA_API_TOKEN.
If a check fails, verify:

​
Data Tables

Each enabled script creates and populates one table: Snapshot model. Every table except the two audit logs is a per-run snapshot stamped with run_at. Query the latest with WHERE run_at = (SELECT MAX(run_at) FROM <table>). Older snapshots are pruned automatically at the end of each run. Audit logs keep everything. confluence_audit_records and jira_org_events are never pruned. The first run reads back as far as Atlassian keeps (the Confluence audit log’s retention setting, at most a year; for the organization log, the last 180 days), and every later run reads forward from the newest record already stored. Filter them on creation_date / event_time, not run_at. Confluence audit records have no id of their own, so ConfigView identifies each one by a fingerprint (record_hash) of its time, author, summary, category, IP address and affected objects; two records identical in all of those are stored once. Names and emails. Confluence’s APIs return account ids, not names. principal_email, principal_name and author_email are filled in from the latest jira_users / jira_groups snapshot when the Confluence script runs, so run Users and Groups too. confluence_space_permissions is built from the latest confluence_spaces snapshot, so run Confluence Spaces before Confluence Space Permissions. Anonymous and guest access. In space permissions, anonymous (not logged in) access is a role principal with id ANONYMOUS, flagged is_anonymous = 1; guest access is flagged is_guest = 1. Installed apps. Atlassian does not publish an API for listing a Cloud site’s apps. ConfigView reads the Universal Plugin Manager, which works on Cloud for site admins but is not guaranteed: Forge apps may not appear, and Atlassian’s own bundled plugins can be marked as user-installed. Filter on user_installed = 1 AND is_atlassian = 0 for the apps your admins added. If Atlassian closes the endpoint the script records nothing and does not fail. jira_group_members is built from the latest jira_groups snapshot, so enable and run Groups before (or alongside) Group Members. jira_settings.source distinguishes the two origins: configuration (global feature flags like attachments/voting/time-tracking, with nested time-tracking keys flattened as timeTrackingConfiguration.workingHoursPerDay) and application-property (advanced settings, which require a Jira admin token). jira_api_tokens timestamps (created_at, expires_at, last_active_at) are stored as raw ISO-8601 strings exactly as Atlassian returns them. An empty expires_at means the token never expires — useful for security audits.

​
Troubleshooting