1. Overview
The Jira integration uses Atlassian OAuth 2.0 authorization to read projects, issues, comments, attachments, users, and workflow metadata from one verified Jira Cloud site.
The immutable Atlassian cloud ID, not the site name or URL, binds the provider account to the exact Seedling connection.
2. Connection and scope
Seedling verifies the provider account before storing the connection. A personal connection remains actor-owned; a workspace connection is administered for the selected Seedling workspace. Credentials are never inferred from an email address or silently promoted between scopes.
- Customer-managed Atlassian OAuth app
- The customer creates a Jira OAuth 2.0 (3LO) app, authorizes the read scopes, and supplies access and refresh tokens. Cloud ID is optional unless the grant reaches multiple sites.
- Personal or workspace connection
- The token inherits the authorizing Atlassian user's native access. Seedling resolves one accessible Jira Cloud site before storing the connection.
3. Jira data Seedling accesses
Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.
- Projects and issues
- Project identity and issue summaries, descriptions, types, status, priority, assignee, reporter, labels, components, versions, parents, resolution, and timing.
- Discussion and files
- Issue comments and attachment metadata or content available to the authorized user.
- People and workflow context
- Visible user identity plus issue fields and project metadata needed to interpret assignment and lifecycle state.
4. Read-only permission contract
Seedling's base Jira connection uses two read scopes plus offline access for token renewal.
- read:jira-work — read Jira projects, issues, fields, comments, attachments, and workflow metadata available to the user.
- read:jira-user — read visible Jira user identity used for attribution.
- offline_access — receive and use a refresh token for recurring synchronization.
- Seedling does not require manage:jira-webhook for the current polling-based connector and does not request Jira write scopes.
5. Security and access
- Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
- Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
- The provider does not expose enough object-level audience evidence for Seedling to reproduce every native permission safely. Workspace content therefore follows the connection's restricted-by-default policy; administrators and stewards receive no raw-content bypass.
- Personal-connection raw content remains visible only to the connecting member in human-facing Seedling surfaces.
- Generated output cannot bypass Seedling's human review, verification, and approval gates.
6. Retention and deletion
- Connected data
- Synchronized Jira records remain while the connection is active and are removed through a durable integration purge after disconnect.
- Credentials
- Stored Jira credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.
- Backups
- Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.