Connect Jira to Parabola

Pull Jira issues, projects, sprints, and users into Parabola via JQL to automate sprint reporting, SLA tracking, and cross-system project visibility.

Jira is Atlassian’s project and issue tracking platform, used by engineering, product, and ops teams to manage bugs, features, sprints, and roadmaps. Connecting Jira to Parabola lets ops, support, and program management teams pull issues, sprints, and project data into the same flows used for support tickets, customer data, and reporting, without manual exports or custom scripts.

Pull from Jira

The Pull from Jira step retrieves issues, projects, users, and field metadata from your Jira Cloud instance. Use JQL to filter precisely so you only pull what your flow needs.

How to authenticate

Jira supports two auth methods. Most teams should start with Basic Auth using an Atlassian API token; OAuth 2.0 is available when stricter scoping is required.

Option 1: Basic Auth with an API token (recommended)

1. Log in to your Atlassian account at https://id.atlassian.com/manage-profile/security.

2. Go to Security → API tokens and click Create API token. Give it a descriptive name and copy the token (you’ll only see it once).

3. In Parabola, add a Pull from Jira step and click Authenticate, then pick Basic Auth.

4. Enter your Atlassian email as the username and paste the API token as the password.

Option 2: OAuth 2.0

1. Open the Atlassian Developer Console and create a new OAuth 2.0 integration (or pick an existing one).

2. Note the Client ID and Client Secret. Set the callback URL to https://parabola.io/api/steps/generic_api/callback.

3. Configure scopes for your use case (for example, read:jira-work, read:jira-user).

4. In Parabola, add a Pull from Jira step, click Authenticate, pick OAuth 2.0, and enter your Client ID and Client Secret. Complete the OAuth flow when prompted.

Available data

The Pull from Jira step covers the endpoints most teams need for reporting. For anything not exposed natively, use a Pull from an API step pointed at the Jira REST API.

• Issues — issue details: summary, description, status, priority, assignee, reporter, dates, custom fields, comments, attachments, and work logs.
• Issue search (JQL) — JQL-based queries against the issue index, with custom field selection and pagination. The most common Jira pull.
• Issue transitions — workflow transitions available for an issue, plus the screens and fields each transition requires.
• Projects — project metadata: name, key, lead, description, issue types, components, versions, and category.
• Project versions — release versions with dates, descriptions, archived/released flags, and issue counts by status.
• Users — display names, emails (subject to privacy settings), account IDs, active flag, and avatar URLs.
• Fields — system and custom field schemas with allowed values.
• Sprints and boards — agile board metadata and sprint contents (via Pull from an API against the Agile API).

Common use cases

• Sprint and release reporting: Pull issues filtered by sprint or fix version, calculate completion rates and velocity, and drop the result into Google Drive, Smartsheet, or a Slack summary for the standup.
• Tie support tickets to engineering work: Join Jira issues with tickets from Zendesk, Front, or Gorgias on a custom field to track which customer issues are blocked on engineering.
• Capacity and workload analysis: Pull issues and assignees, group by team and status, and surface bottlenecks before they hit standup. Pair with a CRM like HubSpot to weight by customer impact.
• SLA monitoring: Combine issue creation, status transitions, and resolution timestamps to track time-to-resolution against SLA targets and alert on breaches via Slack or Twilio SMS.
• Stale-ticket reminders: Query for issues open longer than N days with no recent activity and ping the assignee in Slack, or post a list to a project Asana board.
• Send Jira data to your warehouse: Push issue history into Snowflake, BigQuery, or Redshift for long-term velocity, defect-rate, and cycle-time analysis joined to the rest of the business.

Tips for using Parabola with Jira

• Use JQL to filter at the source. Filtering with JQL (project = PROJ AND status = "In Progress" AND updated >= -7d) is faster than pulling all issues and filtering downstream, and it stays under Jira’s row limits.
• Request only the fields you need. Set fields=summary,status,assignee,updated in the search query to keep payloads small. Pulling every custom field on a busy project gets slow fast.
• Pull issues and users separately, then join. Issue payloads return assignees as account IDs. To get display names and emails, pull Users and join on accountId. Same pattern for reporters and watchers.
• Watch user privacy settings. Atlassian privacy controls can null out email addresses on the Users endpoint. If you need to map issues to email-based identities elsewhere, use a stable account ID as the join key.
• Match cadence to use case. Hourly for live ops dashboards and stale-ticket reminders, daily for sprint and SLA reporting, weekly for velocity and trend analysis.
• Handle pagination. The Jira search API returns 50–100 issues per page by default. Parabola handles pagination, but very large queries can hit rate limits — narrow the JQL or run the flow more frequently.

FAQ

Can I create or update Jira issues from Parabola?

Yes. Use a Send to an API step pointed at the Jira REST API (POST /rest/api/3/issue to create, PUT /rest/api/3/issue/{issueIdOrKey} to update) with the same Basic Auth credentials. Each row of data becomes one API call.

Does Parabola support Jira webhooks?

Yes, indirectly. Configure a Jira webhook (issue created, issue updated, issue transitioned) to point at a Parabola webhook trigger on a separate flow. The flow runs on each event.

How do I pull sprint or board data?

Sprints and boards live on the Agile API (/rest/agile/1.0/). Use a Pull from an API step against /rest/agile/1.0/board and /rest/agile/1.0/sprint/{sprintId}/issue with the same credentials.

What’s the difference between issue search and the issues endpoint?

Issue search runs JQL and returns matching issues with paging and field filtering — that’s what most reporting flows use. The single-issue endpoint (/rest/api/3/issue/{key}) returns one issue’s full payload, useful when you already have the key and want every field.

Why do I see fewer issues than expected?

Two common causes: JQL filters are stricter than you think (try the same query in Jira’s search UI), or the user account behind your token doesn’t have permission to see those projects. Verify in Jira that the account can open the issues directly.

---

With Jira and Parabola connected, the sprint reports, SLA dashboards, and ticket-to-issue reconciliations your team rebuilds every week run on a schedule with output landing in the systems where work actually happens.