> ## Documentation Index > Fetch the complete documentation index at: https://docs.app.strix.ai/llms.txt > Use this file to discover all available pages before exploring further. # Jira Integration > Connect Strix to Jira Cloud, or to a self-hosted Jira on an on-prem Strix install, to export vulnerabilities as issues and keep statuses in sync export const ScarfPixel = () => ; Strix connects natively to Jira Cloud. Strix can export the vulnerabilities that scans and PR reviews find as Jira issues, and keep the statuses synchronized in both directions. This page describes the setup, the OAuth scopes that Strix requests, the data that Strix and Jira exchange, and the disconnect procedure. ## Overview | | | | - | - | | Integration type | Native Atlassian OAuth 2.0 (3LO) app — no third-party middleware in the data path | | Direction | Bidirectional. Strix creates and updates issues. Jira status changes come back through a webhook | | Who can connect | Strix organization **admins** only | | Jira products touched | Jira Cloud (through the `api.atlassian.com` gateway, scoped to one site and cloud ID) | | Hosting | Jira Cloud on hosted Strix. Self-hosted Jira Data Center or Server on on-prem Strix installs only (see [Self-hosted Jira](#self-hosted-jira-on-prem-strix-only)) | ## Setup 1. In Strix, go to **Settings → Integrations** and click **Connect** on the Jira card. You must be an organization admin, and your plan must include ticketing integrations. 2. Strix opens the standard Atlassian consent screen (`auth.atlassian.com`). Sign in with a Jira account that can browse projects and create issues in the target projects. Then approve the requested scopes. 3. Atlassian redirects back to `https://app.strix.ai/api/integrations/jira/callback`. Strix exchanges the authorization code for tokens, records the Jira site (cloud ID and site URL), and registers a webhook for inbound status synchronization. 4. In Strix, select a **default project** (and, if you want, a default issue type) as the export destination. You can also enable **auto-sync** with a minimum severity. Auto-sync exports new findings automatically. 5. Optional: route findings to other projects. Under **Route by source**, select a project for pentests, PR reviews, or supply-chain findings. Under **Route by repository**, select a project for findings from one repository. Both cards sit under **Advanced** on the settings page and are collapsed by default. See [Route tickets](#route-tickets). If the authorizing Atlassian account has access to more than one Jira site, Strix connects the first accessible site. If you have more than one site, use an account that has access only to the applicable site. ## Route tickets Strix can send findings to different Jira projects. Jira and Linear share the same routing model. Strix resolves the destination of each ticket in this order: 1. The destination that you select in the export dialog. 2. The repository route of the repository that the finding belongs to. 3. The source route of the finding source. 4. The default project. Manual exports, bulk exports, the API, and auto-sync all use the same order. ### Route by source Open **Settings → Integrations**, click **Configure** on the Jira card to open its settings page, and expand **Route by source** under **Advanced**. The card shows one destination for each source: | Source | Findings | | - | - | | Pentests | Findings from pentests (API key `scan`) | | PR reviews | Findings from pull request reviews | | Supply chain | Dependency vulnerabilities (`finding_class` is `dependency_cve`) | If a source has no destination, Strix uses the default project. ### Route by repository Click **Add repository route…** and select a repository. Then select the project for its findings. Strix matches a pentest finding through the repositories of the pentest and a PR review finding through the repository of the pull request. A repository route has priority over a source route. ### Required fields on routed projects If a routed project has required fields, the route shows the same field editors as the default project. Strix saves the route when every required field has a value. Each route can also use its own issue type. ### Set routes through the API The `source_routes` object replaces the stored source routes. To use the default destination for a source, set the key to `null` or leave the key out. The `repository_routes` array replaces the stored repository routes. A repository that is not in the array loses its route. For each route, `ticket_type` and `jira_field_values` are optional. Strix rejects a route that misses a required field. ```bash theme={null} curl -X PATCH "https://app.strix.ai/api/v1/integrations/jira/settings" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "source_routes": { "supply_chain": { "collection_id": "", "collection_name": "Dependencies", "ticket_type": "Bug", "jira_field_values": { "customfield_10001": { "value": "", "label": "Platform" } } } }, "repository_routes": [ { "repository_id": "", "collection_id": "", "collection_name": "Payments" } ] }' ``` `GET /api/v1/integrations/jira/settings` returns the stored routes and, for administrators, the connected repositories with their identifiers. **Required scope:** `integrations:write` ## Ticket defaults The Jira settings page (**Settings → Integrations → Configure**) holds the defaults that Strix applies to every ticket that it creates. Manual exports, bulk exports, the API, and auto-sync use the same defaults. ### Default assignee Select a Jira user in **Default assignee**. Strix lists the users that Jira can assign in the default project. Strix assigns every new ticket to that user. Leave the field empty to create unassigned tickets. If a route sends a finding to a different project, the user must also be assignable in that project; if not, Strix stops the export with an error that tells you to change the assignee or the route. ### Title and description templates Strix renders the ticket title and description from templates. A template mixes text with placeholders in double braces. The default title template is `{{title}}` and the default description template is `{{details}}`. | Placeholder | Value | | - | - | | `{{title}}` | The finding title | | `{{severity}}` | The severity, for example `high` | | `{{cve}}` | The CVE identifier of a dependency finding, or empty | | `{{cvss}}` | The CVSS score, or empty | | `{{target}}` | The target of the pentest | | `{{endpoint}}` | The affected endpoint or file | | `{{repository}}` | The repository of the finding | | `{{pentest}}` | The name of the pentest | | `{{source}}` | `Pentests`, `PR reviews`, or `Supply chain` | | `{{strix_url}}` | The link to the finding in Strix | | `{{details}}` | The full finding description that Strix writes today | Strix rejects a template that contains an unknown placeholder. A title template can hold 500 characters and a description template 20,000 characters. ### Group tickets by pentest Turn on **Group tickets by pentest** to collect the tickets of one pentest under one Jira Epic in the selected project. The project needs an Epic issue type. On Jira Server and Data Center, the issue create screen also needs the **Epic Link** field. Strix creates the Epic the first time that it exports a finding from the pentest and reuses it afterwards. Tickets from PR reviews and supply chain findings are not grouped. ### Priority and due date Turn on **Set Jira priority from severity** to map each Strix severity to one of the default Jira project's priorities. Strix lists the priorities on that project's create screen — the only ones Jira accepts when it creates a ticket — and prefills the mapping by matching the priority names (for example `Highest` to critical and `Low` to low); adjust any severity in the table. A severity left on **Jira default** creates tickets without a priority, so Jira applies its own default. If the project's create screen has no Priority field, add it to that screen in Jira first; the same applies when no default project is picked. Turn on **Due date by severity** to set a due date on every new ticket, counted in days from the day that Strix creates it. Give each severity a number of days or leave it blank for no due date. Both settings apply to every new ticket — manual exports, bulk exports, the API, and auto-sync. They never change tickets that Strix already created. If Jira rejects the priority or the due date when Strix creates a ticket (for example the issue create screen hides the field), Strix retries the create without that field so the ticket still lands. Set them through the API with `jira_priority_map` and `due_date_days` on `PATCH /api/v1/integrations/jira/settings`. `jira_priority_map` maps each severity (`critical`, `high`, `medium`, `low`) to `{"id": ""}` or `null`; Strix validates the ids against the priorities that `GET /api/v1/integrations/jira/priorities` returns — the priorities on the default project's create screen, or the `collection_id` project when that query parameter is given — and stores the name that Jira reports. `due_date_days` maps each severity to a whole number of days from 1 to 365, or `null`. Send `null` for either field to turn it off. ### Preview and test ticket Click **Preview ticket** to see the rendered title, description, destination, and assignee of a sample finding. Click **Send test ticket** to create a real ticket in the default project from the same sample. **Send test ticket** requires the administrator role. ### Set defaults through the API ```bash theme={null} curl -X PATCH "https://app.strix.ai/api/v1/integrations/jira/settings" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "default_assignee_id": "", "title_template": "[{{severity}}] {{title}}", "description_template": "{{details}}\n\nStrix: {{strix_url}}", "group_by_pentest": true }' ``` Set `default_assignee_id` to `null` to remove the assignee and a template to `null` to restore the default. Strix validates the assignee against the users that `GET /api/v1/integrations/jira/users` returns. | Method | Path | Purpose | Scope | | - | - | - | - | | `GET` | `/api/v1/integrations/jira/users` | List the users that Strix can assign | `integrations:read` | | `GET` | `/api/v1/integrations/jira/priorities` | List the priorities on the default (or `collection_id`) project's create screen | `integrations:read` | | `GET` | `/api/v1/integrations/jira/preview` | Preview a sample ticket with the stored defaults | `integrations:read` | | `GET` | `/api/v1/vulnerabilities/{vulnerabilityId}/preview` | Preview the ticket for one finding | `integrations:read` | The finding preview has a `mode` field. `create` shows the ticket that a push opens, with its `destination`. `update` means that the finding already has a ticket: a push only updates its description and status, so `existing_ticket` gives the link to it and `destination` and `ticket.title` are `null`. \| `POST` | `/api/v1/integrations/jira/test-ticket` | Create a test ticket in the default project | `integrations:write` | ## OAuth scopes requested | Scope | Why Strix needs it | | - | - | | `read:jira-work` | List projects and issue types, and read issue status during synchronization | | `write:jira-work` | Create issues, post status comments, and transition issues | | `read:jira-user` | Atlassian requires this scope for issue operations that resolve users | | `manage:jira-webhook` | Register and refresh the webhook for inbound status synchronization | | `offline_access` | Receive a refresh token so that the connection continues after the access token expires | Access tokens are short-lived. Strix refreshes them automatically with the rotating refresh token. All API calls go through `https://api.atlassian.com/ex/jira//rest/api/3` and apply only to the one connected site. ## What data flows where **Strix → Jira** (when you export a vulnerability manually, or when auto-sync exports it): * Issue summary: the vulnerability title (shortened to the Jira limit). * Issue description: severity, CVSS and CVE (when present), target, endpoint or affected file, impact, technical analysis, evidence, suggested fix or remediation steps, proof of concept, and a link back to the issue in Strix. * Priority mapped from severity, and a due date when an issue is snoozed. * Status comments (for example, "marked In Progress by …") when the Strix status changes. **Jira → Strix** (through a webhook on `jira:issue_updated`): * The issue ID and key, its status category (new, in progress, or done), the due date, and the display name of the user who made the change. Strix applies the status category to the status of the linked vulnerability. Strix does not read existing Jira issues, attachments, comments, or user directories. Inbound processing applies only to status and due-date updates for the issues that Strix created. ## Security * **Admin-gated**: The connect and callback endpoints require an authenticated Strix org admin. Strix checks the role again at the callback. Thus a demoted user cannot complete a pending connection. * **CSRF-protected OAuth**: The OAuth `state` is HMAC-signed and bound to the initiating organization and user. It expires after 10 minutes. * **Webhook verification**: Atlassian does not sign Jira dynamic webhooks. Thus the callback URL contains a per-connection random secret. Strix compares this secret (in a timing-safe operation) with the stored value before it processes a payload. * **Token storage**: Strix keeps the access and refresh tokens server-side in its database. The tokens apply only to your organization. The browser and other tenants cannot see them. * **One webhook URL per Atlassian account**: Atlassian accepts one webhook URL for each Atlassian account and OAuth app. If the account that connects Jira already sends Strix webhooks from another Strix workspace, the connection completes without the webhook. Exports work, but Jira status changes do not flow back. The Integrations page shows **Connected, status sync off**. To enable the sync, disconnect Jira in the other workspace, then reconnect it here. * **Revocation on disconnect**: When you disconnect the integration, Strix deletes the webhook and revokes the Atlassian grant. Refresh-token revocation makes the full grant invalid. Thus no live tokens stay on the Atlassian side. * **Audit trail**: The Strix audit log records the connection of the integration and the changes to the settings. ## Self-hosted Jira (on-prem Strix only) An on-prem Strix install can connect to a Jira Data Center or Jira Server instance on the same network. Hosted Strix (`app.strix.ai`) does not offer this option. The **Connect** button on the Jira card asks which Jira you use: **Jira Cloud** starts the Atlassian OAuth flow above, and **Self-hosted Jira** opens a form for the instance URL and a personal access token. 1. In Jira, create a personal access token under **Profile → Personal Access Tokens**. The token owner must be able to create issues in the target projects. 2. In Strix, click **Connect** on the Jira card and select **Self-hosted Jira**. 3. Enter the instance URL (for example `https://jira.internal.example.com`) and the token. Then click **Connect**. If the token owner is a Jira administrator, Strix registers the status webhook on the instance. If not, the dialog shows a webhook URL one time. Ask a Jira administrator to add this URL under **System → Webhooks** with the **Issue updated** event. Strix stores the token encrypted and uses the Jira REST API v2 on your instance. The export, status sync, and disconnect behavior is the same as for Jira Cloud. The same connection is available through the API on on-prem installs: ```bash theme={null} curl -X POST "https:///api/v1/integrations/jira/server/connect" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"instance_url": "https://jira.internal.example.com", "access_token": ""}' ``` **Required scope:** `integrations:write`. Hosted Strix returns `404` for this route. ## Disconnecting An org admin can disconnect Jira at any time from **Settings → Integrations**, or through the API: ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/integrations/jira" \ -H "Authorization: Bearer " ``` **Required scope:** `integrations:write` The disconnect operation removes the stored tokens, deletes the Jira webhook, and revokes the OAuth grant. Strix does not delete the issues that it already created in Jira. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.