Reference · built on requestConnectorSupport & service desks

Jira Service Management

Customer requests, queues, SLA metrics, approvals, and comments from Jira Service Management Cloud.

Request accessPricing ↗

About

Jira Service Management is Atlassian's service desk built on Jira Cloud. A service desk project holds request types, queues, customers, and organizations. Each customer request is a Jira issue with SLA metrics, approvals, participants, and comments that are either public to the customer or internal. The Cloud REST API lives under /rest/servicedeskapi and pages results with start, limit, size, and isLastPage.

Through Fibric, an operator reads the queues and SLA state, receives Jira webhooks for new issues and comments, and proposes a comment, a transition, a participant, or an approval decision for your approval. Each approved change is applied once and leaves a record of what changed and how to undo it.

This is a reference listing. It documents what Fibric would read from Jira Service Management and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Customer requests through GET /rest/servicedeskapi/request and /request/{issueIdOrKey}, with request type, status, reporter, and participants
  • Queues and the issues in each queue through /servicedesk/{serviceDeskId}/queue/{queueId}/issue
  • SLA metrics on a request through /request/{issueIdOrKey}/sla and /sla/{slaMetricId}
  • Comments on a request, public or internal, and their attachments
  • Approvals on a request and each decision through /request/{issueIdOrKey}/approval
  • Customers, organizations, request types, and request type fields on a service desk; customer feedback on a request
  • Jira webhooks such as jira:issue_created, jira:issue_updated, and comment_created, filtered by JQL on project, status, priority, or assignee

Proposed actions

  • Target capability: propose a public or internal comment through POST /rest/servicedeskapi/request/{issueIdOrKey}/comment using the public flag
  • Target capability: propose a status change through POST /rest/servicedeskapi/request/{issueIdOrKey}/transition, chosen from the transitions listed for that request
  • Target capability: propose adding participants through POST /rest/servicedeskapi/request/{issueIdOrKey}/participant
  • Target capability: propose an approval decision through POST /rest/servicedeskapi/request/{issueIdOrKey}/approval/{approvalId}
  • Target capability: propose a new customer request through POST /rest/servicedeskapi/request after checking it with /request/validate

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Act on an SLA metric before it breaches

    The operator polls /sla on the issues in a queue and proposes a transition or an internal comment to the assignee while the metric still has time left.

    With Breach Watch

  • Assemble the packet for a stalled request

    When a request sits in a queue past its due time, the operator gathers comments, approvals, and SLA state and proposes adding a participant with a summary comment.

    With Escalation Packet

  • Acknowledge a new request with the right article

    On jira:issue_created the operator reads the request type, searches the linked knowledge base, and proposes a public comment with the article link.

    With First Response, Ticket Triage

Requirements

  • A Jira Service Management Cloud site with at least one service desk project
  • An OAuth 2.0 (3LO) app granted read:servicedesk-request and write:servicedesk-request, or an Atlassian API token for basic authentication
  • The cloudId of the site for OAuth calls through https://api.atlassian.com/ex/jira/{cloudId}/rest/servicedeskapi
  • A webhook registered by a Jira administrator, or through POST /rest/api/3/webhook, which is open to OAuth 2.0 and Connect apps only
Authentication
OAuth 2.0 (3LO) with scopes such as read:servicedesk-request and write:servicedesk-request, called through api.atlassian.com/ex/jira/{cloudId}; basic authentication with an Atlassian API token serves personal scripts.

Limits

  • Rate limits return HTTP 429 with Retry-After; hourly point quotas, per-second burst limits, and per-issue write limits apply at the same time
  • Webhooks registered through POST /rest/api/3/webhook expire 30 days after creation or refresh unless extended through PUT /rest/api/3/webhook
  • Jira webhooks carry issue and comment events; no SLA or approval events are documented, so SLA state is read by polling /request/{issueIdOrKey}/sla
  • Methods marked experimental require the X-ExperimentalApi: opt-in header and may change without notice

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Jira Service Management ↗

Questions and answers

Does Jira Service Management have its own webhooks?
No. Jira Cloud webhooks cover service desk projects. Events include jira:issue_created, jira:issue_updated, comment_created, and comment_updated, filtered by JQL clauses such as project, status, priority, and assignee. Webhooks registered through POST /rest/api/3/webhook expire after 30 days unless refreshed.
How does the API separate internal notes from customer replies?
By the public field on a request comment. POST /rest/servicedeskapi/request/{issueIdOrKey}/comment takes public true for a reply the customer sees and false for an internal comment. GET on the same path returns both kinds, and each comment lists its attachments.
What happens when the connector hits a rate limit?
Jira returns HTTP 429 with Retry-After. X-RateLimit-Limit and X-RateLimit-Remaining report capacity, X-RateLimit-NearLimit turns true when under 20 percent remains, and RateLimit-Reason names the limit that was hit. The connector waits the stated seconds and retries with backoff.
Ask about Jira Service Management

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Jira Service Management through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy