Reference · built on requestConnectorWork & ticket management

Jira

Issues, projects, sprints, and workflow transitions from Jira Cloud sites through the Jira Cloud platform REST API and webhooks.

Request accessPricing ↗

About

Jira is Atlassian's issue tracker. A Jira Cloud site holds projects, issues, comments, worklogs, sprints, boards, and versions, and each issue moves through a workflow of transitions. The Jira Cloud platform REST API exposes them under /rest/api/3 on your site. Version 3 accepts Atlassian Document Format in comment bodies, issue descriptions, and multi-line custom fields.

Through Fibric, an operator watches issue and comment webhooks, reads the issue and its changelog, and proposes a transition, an assignment, or a comment for your approval. Each approved change leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Jira 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

  • Issues and their fields through GET /rest/api/3/issue/{issueIdOrKey}, with the expand parameter for rendered fields and changelogs
  • Issue lists from JQL through the enhanced search endpoints GET and POST /rest/api/3/search/jql, paged with nextPageToken
  • Issue history through GET /rest/api/3/issue/{issueIdOrKey}/changelog and POST /rest/api/3/changelog/bulkfetch
  • Comments on an issue through GET /rest/api/3/issue/{issueIdOrKey}/comment
  • Available transitions for an issue through GET /rest/api/3/issue/{issueIdOrKey}/transitions
  • Webhook events such as jira:issue_created, jira:issue_updated, comment_created, sprint_started, and sprint_closed, filtered by JQL where supported

Proposed actions

  • Target capability: propose a workflow transition through POST /rest/api/3/issue/{issueIdOrKey}/transitions
  • Target capability: propose an assignee change through PUT /rest/api/3/issue/{issueIdOrKey}/assignee
  • Target capability: propose a comment through POST /rest/api/3/issue/{issueIdOrKey}/comment
  • Target capability: propose a field edit through PUT /rest/api/3/issue/{issueIdOrKey}, or a new issue through POST /rest/api/3/issue

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

What you can build

  • Assemble an escalation packet

    When a support case needs engineering, the operator drafts a Jira issue with the customer history attached, proposes it for approval, and links the issue key back to the case.

    With Escalation Packet

  • Keep a change freeze honest

    The operator reads issues transitioning toward release inside a freeze window and proposes a comment and a hold transition before the change goes out.

    With Change Freeze

  • Chase actions that stall

    Issues assigned from a review that show no changelog activity past a threshold get a proposed reminder comment or reassignment, listed for you to approve.

    With Action Follow-up

  • Write the root cause up

    After an incident, the operator gathers the linked issues, their transitions, and their comments into a draft the reviewer edits before it is filed.

    With Root Cause

Requirements

  • A Jira Cloud site; calls go to https://<site-url>/rest/api/3, or to https://api.atlassian.com/ex/jira/<cloudId>/rest/api/3 for OAuth 2.0 apps
  • A user or app whose Jira permissions cover the projects it reads and writes; the API applies the same restrictions as the web interface
  • A webhook registered by a Jira administrator or through POST /rest/api/3/webhook, delivered to an HTTPS endpoint on an allowed port
Authentication
An OAuth 2.0 (3LO) app with scopes such as read:jira-work and write:jira-work, or an Atlassian API token over basic authentication for ad-hoc calls.

Limits

  • Rate limits apply per tenant and per resource path: an hourly points quota, per-second burst limits, and 20 writes per issue every 2 seconds
  • Webhooks registered by OAuth 2.0 apps expire 30 days after creation or refresh, and each app may hold 5 per user
  • JQL filtering on webhooks covers only some events; sprint and version events cannot be filtered
  • Failed webhook deliveries are retried up to five times; payloads over 25MB are not delivered

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 ↗

Questions and answers

Which API version does the connector use?
Version 3 of the Jira Cloud platform REST API. Versions 2 and 3 offer the same operations; version 3 adds Atlassian Document Format for comment bodies, issue descriptions and environment fields, worklog comments, and textarea custom fields.
How are webhooks secured and delivered?
Admin-created webhooks can carry a secret that Jira uses for a SHA256 HMAC in the X-Hub-Signature header. Primary webhooks are meant to arrive within 30 seconds. Failed calls are retried up to five times, with 5 and 15 minute delays, on 408, 409, 425, 429, 5xx, or timeouts.
What happens when the rate limit is hit?
Jira returns 429 Too Many Requests with a Retry-After header and a RateLimit-Reason header naming the limit that fired. The connector waits the stated seconds before retrying and paces history loads against the hourly points quota.
Ask about Jira

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 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