Atlassian users (WIP)
Pulls the user directory for an Atlassian Cloud organisation, including product access, role assignments, MFA state and last-active dates.
| Type name | atlassian_users |
| Creates | Users |
| Runs on | A sensor with outbound reach to api.atlassian.com and admin.atlassian.com |
| Presence flag | atlassian_user_exists |
| Field prefix | atlassian_ |
What it contributes
- Identity — account ID, display name, email, account type
- Organisation — organisation, job title, department, groups, org roles
- Access — product access, access billable flag
- Account state — active, status, membership status, email verified, claim status, MFA enabled, for-deletion flag
- Lifecycle — added to org, added-to-org timestamp, last active
- Locale — time zone, locale
atlassian_mfaEnabled is a direct control gap when false. atlassian_access_billable
combined with atlassian_last_active finds seats being paid for and not used.
Neither is visible anywhere else in the inventory.
Requirements
The integration is outbound-only: it is a scheduled API client, so nothing is installed in the Atlassian organisation and nothing has to reach into the deployment.
Network access
| From | To | Protocol | Port |
|---|---|---|---|
| The sensor running the integration | api.atlassian.com — the user list and last-active dates | HTTPS over TCP | 443 |
| The sensor running the integration | admin.atlassian.com — per-user directory detail and role assignments | HTTPS over TCP | 443 |
| The sensor running the integration | Your site, e.g. company.atlassian.net | HTTPS over TCP | 443 |
Three hosts, because Atlassian splits the directory across the organisation APIs and the site itself — the same split that makes two credentials necessary. If the sensor reaches the internet through a proxy, point Proxy settings at it rather than opening direct egress.
Access in Atlassian
| Need | Why |
|---|---|
| An organisation admin account | The directory, role-assignment and last-active endpoints are all admin-scoped — see Permissions in Atlassian |
| The ability to create a user API token for the site | Paired with the account's email as basic auth against the site |
| The ability to create an organisation API token | A separate admin key for the organisation-level endpoints; the two are not interchangeable |
| The organisation ID | Read from the admin console URL — not the site name, as the warning under Permissions in Atlassian explains |
In this deployment
| Need | Why |
|---|---|
| A registered, healthy sensor | The integration runs on a sensor, on the platform's schedule — see Sensors |
There are no special host requirements beyond a sensor that is checking in. Note that per-user directory and role calls make the run scale with directory size rather than with anything on the sensor host.
Configuration
This integration needs two credentials, because Atlassian splits the directory across two APIs.
| Field | Required | Notes |
|---|---|---|
| Name | Yes | Label for this instance |
| Atlassian domain | Yes | Your site, e.g. company.atlassian.net |
| Atlassian email | Yes | Email of the account owning the API token |
| API token | Yes | User API token for the site |
| Organization API token | Yes | Token for the Atlassian Admin API |
| Organization ID | Yes | Atlassian organisation ID |
| Proxy settings | No | http://host:port |
| Sensor | Yes | Sensor that will run the integration |
| Ignore SSL | No | Skips certificate validation |
The API token is a personal token for the site, paired with the email address as basic auth. The organization API token is an admin key that authorises the organisation-level endpoints. They are created in different places and are not interchangeable.
Permissions in Atlassian
The account holding the organisation API token must be an organisation admin — the directory, role-assignment and last-active endpoints are all admin-scoped.
The integration reads:
| Endpoint | Provides |
|---|---|
api.atlassian.com/admin/v1/orgs/{orgId}/users | The user list |
admin.atlassian.com/gateway/api/admin/v2/orgs/{orgId}/directories/-/users/{accountId} | Per-user directory detail |
.../users/{accountId}/role-assignments | Org role assignments |
api.atlassian.com/admin/v1/orgs/{orgId}/directory/users/{accountId}/last-active-dates | Last-active dates per product |
Find it in the admin console URL at admin.atlassian.com/o/<orgId>/. Using the
site domain in its place produces 404s on every organisation endpoint while the
site-level token still authenticates, so the run looks half-working.
Document the API-token rotation story: Atlassian tokens can be given an expiry, and the failure mode for an expired org token versus an expired user token differs.
See also
- Azure users — Entra ID identities, which most Atlassian accounts will also have
- Integrations overview — the shared configuration model