Jira API

Programmatic management of the Jira integration itself: connecting it, reading it back, changing its settings, and disconnecting it. Requests share the same base URL and Bearer token authentication as the rest of the platform API.

Base URL. Your deployment's platform host (for example, https://<your-tenant>.qualytics.io/api).
Auth. Bearer token in the Authorization header. See Access Tokens to create one.
Content type. application/json on every request that carries a body.

Permissions

Every endpoint on this page requires the Manager role. See Permissions.

Complete API Reference

The endpoints below are illustrative. For the full request and response schemas, live examples, and every field that each endpoint accepts, see the interactive API reference at demo.qualytics.io/api/docs.

Looking for tickets and links?

Creating a ticket for an anomaly, searching tickets, and managing the links between anomalies and issues are anomaly operations, not integration ones. They live on the Anomalies API page.

Integration Endpoints

Operation	Method	Endpoint	Description
Create Integration	POST	`/api/integrations`	Connect Jira. The credentials are validated against the instance before the integration is stored.
List Integrations	GET	`/api/integrations`	Return every connected integration, ticketing included.
Get Integration	GET	`/api/integrations/{id}`	Return one integration. Credentials are never returned in plain text.
Update Integration	PUT	`/api/integrations/{id}`	Change the URL, the credentials, the allowed projects, or the sync settings.
Get Integration History	GET	`/api/integrations/{id}/history`	Return the change log of the integration, one entry per saved version, with the user who made each change.
Disconnect Integration	DELETE	`/api/integrations/{id}`	Remove the integration and every anomaly-ticket link with it. The issues in Jira are untouched.

Connection Form Endpoints

These are what the settings modal calls while you fill it in. The POST variants take the credentials being typed, so they work before anything is saved, while the GET variants read through a saved integration.

Operation	Method	Endpoint	Description
Get Integration Specifications	GET	`/api/integrations-specifications`	Return the field specification each integration type's form is built from.
List Projects (unsaved)	POST	`/api/integrations/ticketing/projects`	List the projects reachable with the credentials in the request body.
List Projects (saved)	GET	`/api/integrations/{id}/ticketing/projects`	List the projects reachable with a saved integration's credentials.
List Ticket Statuses (unsaved)	POST	`/api/integrations/ticketing/statuses`	List the ticket statuses reachable with the credentials in the request body, used to build the status mapping.
List Ticket Statuses (saved)	GET	`/api/integrations/{id}/ticketing/statuses`	The same list, through a saved integration.
Get Ticketing Webhook	GET	`/api/integrations/ticketing/webhook`	Return the webhook URL to register in Jira so issue changes reach Qualytics immediately. The secret is minted on the first call.

Request Fields

The create and update bodies share the same shape. Only type is create-only.

parameters is replaced, not merged

An update stores the parameters object exactly as sent, so any key you leave out is dropped. Send the whole object, including projects and default_project_key, even when you are only changing a sync setting. Omitting parameters entirely leaves the stored one untouched.

The credentials are only re-tested against Jira when the request changes api_url or sends a token, so a request that changes projects or sync settings alone is saved without a connection test. The same values are described as they appear in the interface on Add Jira Connection.

Field	Type	Description
`type`	`string`	`jira`. Required on create, and cannot be changed afterwards.
`api_url`	`string`	The Jira instance URL. A trailing slash is stripped.
`api_access_token`	`string`	The credentials, as `email:api_token`. Stored encrypted and never returned.
`parameters.projects`	`array`	The projects Qualytics may create issues in, each `{ "id": ..., "key": ..., "name": ... }`. At least one is required.
`parameters.default_project_key`	`string`	The project used when a caller names none. It has to be one of `parameters.projects`.
`parameters.post_updates`	`bool`	Two-way sync. Absent means on. When false the integration is read only and nothing is written to Jira.
`parameters.sync_statuses`	`bool`	Whether anomaly and issue statuses move together. Defaults to off.
`parameters.status_mapping`	`object`	Anomaly status to ticket status, for example `{"Active": "To Do", "Resolved": "Done"}`. A `null` value leaves that anomaly status unmapped. Required to be non-empty when `sync_statuses` is on.

Sample Requests

Connect Jira

curl -X POST "https://<your-tenant>.qualytics.io/api/integrations" \
  -H "Authorization: Bearer $QUALYTICS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "jira",
    "api_url": "https://your-domain.atlassian.net",
    "api_access_token": "user@example.com:your_api_token",
    "parameters": {
      "projects": [{ "id": "10001", "key": "DATAQ", "name": "Data Quality" }],
      "default_project_key": "DATAQ"
    }
  }'

Returns the stored integration. The credentials are not echoed back.

Turn on status sync with a mapping

curl -X PUT "https://<your-tenant>.qualytics.io/api/integrations/2" \
  -H "Authorization: Bearer $QUALYTICS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "projects": [{ "id": "10001", "key": "DATAQ", "name": "Data Quality" }],
      "default_project_key": "DATAQ",
      "sync_statuses": true,
      "status_mapping": {
        "Active": "To Do",
        "Acknowledged": "In Progress",
        "Resolved": "Done"
      }
    }
  }'

Turning sync_statuses on with nothing mapped is refused, so send the mapping in the same request.

Make the integration read only

curl -X PUT "https://<your-tenant>.qualytics.io/api/integrations/2" \
  -H "Authorization: Bearer $QUALYTICS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "post_updates": false,
      "projects": [{ "id": "10001", "key": "DATAQ", "name": "Data Quality" }],
      "default_project_key": "DATAQ"
    }
  }'

The projects are repeated because parameters is stored exactly as sent. Sending post_updates on its own would drop them, and the request is then refused with 422 because a Jira integration has to name at least one project. Read the integration first when you do not know what it currently holds.

Reading issues back continues. To silence a single issue instead, use the ticket link endpoint on the Anomalies API.

Read the webhook URL

curl -X GET "https://<your-tenant>.qualytics.io/api/integrations/ticketing/webhook" \
  -H "Authorization: Bearer $QUALYTICS_TOKEN"

Returns { "url": "...", "supported": true }. The URL embeds a secret, so treat it as a credential. See Register the Jira Webhook.

Disconnect Jira

curl -X DELETE "https://<your-tenant>.qualytics.io/api/integrations/2" \
  -H "Authorization: Bearer $QUALYTICS_TOKEN"

Removes the integration and every anomaly-ticket link. The issues stay in Jira.