Jira Feeds Data Source

The Jira Feeds connector is specialized for creating data sources in Nexla's ELT data flows. With this connector, you can build a flow that extracts unmodified data from your Jira Cloud instance across a wide range of object types—issues, projects, users, boards, sprints, comments, changelogs, and more—and loads it into any database or data warehouse. This enables fast, seamless data ingestion while preserving the original Jira data structure for downstream analytics.

The Jira Feeds connector enables you to ingest data from your Jira Cloud instance across multiple object types using Jira's REST API v3. Follow the instructions below to create a new data flow that ingests data from a Jira Feeds source in Nexla.

Jira Feeds

Create a New Data Flow

1. To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Then, select the desired flow type from the list, and click the Create button.

2. Select the Jira Feeds connector tile from the list of available connectors. Then, select the credential that will be used to connect to your Jira Cloud instance, and click Next; or, create a new Jira Feeds credential for use in this flow.

3. In Nexla, Jira Feeds data sources are configured using pre-built feed templates that enable multi-object ELT extraction from Jira Cloud. Each feed type corresponds to a specific Jira object type, making it easy to select exactly the data you need.
   • To configure this source using a feed template, follow the instructions in Configure Using a Template.

   Jira Feeds sources can also be configured manually, allowing you to ingest data from any valid Jira REST API v3 endpoint or apply further customizations.
   • To configure this source manually, follow the instructions in Configure Manually.

Configure Using a Template

Nexla provides pre-built feed templates for the Jira Feeds connector that make it easy to extract data from common Jira object types. Each template is pre-configured for the corresponding Jira REST API v3 endpoint, with support for both full and incremental sync strategies.

Feed Settings

• Select the Jira object type from which this source will fetch data from the Endpoint pulldown menu. Available feed templates are listed in the expandable sections below. Click on a feed type to view details and configuration instructions.

Issues

Retrieves Jira issues from your instance using JQL (Jira Query Language). Issues are the core work items in Jira and include bugs, tasks, stories, epics, and any custom issue types defined in your projects. This feed uses the Jira Search API with paginated token-based pagination and supports both full and incremental sync strategies.

• Select Issues from the Endpoint pulldown menu.

• Optionally, enter a JQL filter in the Issue JQL Filter field to restrict which issues are returned. JQL (Jira Query Language) is Jira's built-in search syntax for filtering issues by any field. The default value fetches all issues ordered by ID:

  • Default (all issues): created+is+not+EMPTY+order+by+id+ASC
  • Single project: project=MYPROJECT order by id ASC
  • Date-bounded: updated>="2024-01-01" order by updated ASC
  • Multiple projects: project in (PROJ1, PROJ2) order by id ASC
• The issues feed returns fields including ID, key, summary, status, assignee, reporter, priority, issue type, project, created date, updated date, resolution date, due date, labels, components, fix versions, parent, subtasks, issue links, and resolution.
• For incremental sync, configure the Incremental Sync Lookback Time field with the earliest date from which changes should be captured, in the format YYYY-MM-DD HH:MM (for example, 2024-01-01 00:00). Incremental runs will fetch issues updated on or after the cursor timestamp from the previous run.

JQL must be a bounded query to avoid timeout errors on large Jira instances. Always include an order by clause. For complete JQL syntax documentation, see the Atlassian JQL documentation.

Projects

Retrieves all Jira projects accessible to the authenticated account. Projects in Jira are containers that organize issues, boards, and team members. This feed uses the Jira Projects API with offset-based pagination (full sync only).

• Select Projects from the Endpoint pulldown menu.
• No additional configuration is required. The feed automatically retrieves all projects the authenticated user has Browse Projects permission to access.
• Returned data includes project ID, key, name, description, project type, lead, and URL.

The number of projects returned depends on the permissions of the Jira account used in the Nexla credential. To access all projects in your Jira instance, use an account with Jira Administrator permissions or a service account with Browse Projects access to all projects.

Project Categories

Retrieves all project categories defined in your Jira instance. Project categories are labels used to group related projects together, and are managed by Jira administrators. This feed is a static (non-paginated) endpoint that returns all categories in a single request.

• Select Project Categories from the Endpoint pulldown menu.
• No additional configuration is required. All project categories visible to the authenticated account are returned automatically.
• Returned data includes category ID, name, and description.

Issue Types

Retrieves all issue types defined in your Jira instance. Issue types classify the nature of a Jira issue—common examples include Bug, Task, Story, Epic, and Sub-task. Custom issue types created by your Jira administrator are also included. This is a static endpoint that returns all types in a single request.

• Select Issue Types from the Endpoint pulldown menu.
• No additional configuration is required. All issue types defined in the Jira instance are returned automatically.
• Returned data includes issue type ID, name, description, icon URL, and whether the type is a subtask type.

Issue Priorities

Retrieves all issue priority levels defined in your Jira instance. Priorities indicate the urgency of a Jira issue—default levels include Highest, High, Medium, Low, and Lowest. This is a static endpoint that returns all priorities in a single request.

• Select Issue Priorities from the Endpoint pulldown menu.
• No additional configuration is required. All priorities are returned automatically.
• Returned data includes priority ID, name, description, icon URL, and status color.

Statuses

Retrieves all workflow statuses defined in your Jira instance. Statuses represent the stages in a Jira workflow through which issues progress—common examples include To Do, In Progress, In Review, and Done. This is a static endpoint that returns all statuses in a single request.

• Select Statuses from the Endpoint pulldown menu.
• No additional configuration is required. All workflow statuses are returned automatically.
• Returned data includes status ID, name, description, and the status category (To Do, In Progress, or Done).

Versions

Retrieves all versions (also called fix versions or releases) across all projects in your Jira instance. Versions are used to organize releases and track which issues are targeted for or resolved in a given release. This is a project-child feed that iterates over all projects to retrieve their associated versions.

• Select Versions from the Endpoint pulldown menu.
• No additional configuration is required. The feed automatically iterates over all accessible projects and retrieves their versions.
• Returned data includes version ID, name, description, release date, released status, and archived status, along with the parent project key.

Components

Retrieves all components across all projects in your Jira instance. Components are sub-sections of a Jira project used to group issues into smaller parts, such as front-end, back-end, API, or documentation. This is a project-child feed that iterates over all projects to retrieve their components.

• Select Components from the Endpoint pulldown menu.
• No additional configuration is required. The feed automatically iterates over all accessible projects and retrieves their components.
• Returned data includes component ID, name, description, lead, and the parent project key.

Fields

Retrieves all fields defined in your Jira instance, including both system fields and any custom fields created by your Jira administrator. This is useful for understanding your Jira schema and mapping field IDs to human-readable names. This is a static endpoint that returns all fields in a single request.

• Select Fields from the Endpoint pulldown menu.
• No additional configuration is required. All fields are returned automatically.
• Returned data includes field ID, name, custom flag, orderable flag, navigable flag, searchable flag, and schema information.

Resolutions

Retrieves all resolution types defined in your Jira instance. Resolutions describe why an issue was closed—common examples include Fixed, Won't Fix, Duplicate, Cannot Reproduce, and Done. This is a static endpoint that returns all resolutions in a single request.

• Select Resolutions from the Endpoint pulldown menu.
• No additional configuration is required. All resolutions are returned automatically.
• Returned data includes resolution ID, name, and description.

Issue Link Types

Retrieves all issue link types defined in your Jira instance. Issue link types define how issues can be related to one another—common examples include Blocks, Clones, Duplicates, and Relates to. This is a static endpoint that returns all link types in a single request.

• Select Issue Link Types from the Endpoint pulldown menu.
• No additional configuration is required. All issue link types are returned automatically.
• Returned data includes link type ID, name, inward description, and outward description.

Users

Retrieves all users accessible to the authenticated account. This feed uses the Jira Users Search API with offset-based pagination and returns all users with access to the Jira instance. This is useful for building user dimension tables or mapping account IDs to user details.

• Select Users from the Endpoint pulldown menu.
• No additional configuration is required. The feed automatically paginates through all users in the Jira instance.
• Returned data includes account ID, account type, display name, email address, and active status.

The Jira Users Search API requires the authenticated account to have Browse Users and Groups permission in Jira. Without this permission, the API may return an empty result or only the current user.

Boards

Retrieves all Jira boards (Scrum and Kanban) accessible to the authenticated account using the Jira Agile REST API. Boards are the primary interface for agile teams to visualize and manage their work. This feed uses the Agile API with offset-based pagination.

• Select Boards from the Endpoint pulldown menu.
• No additional configuration is required. All boards accessible to the authenticated account are returned automatically.
• Returned data includes board ID, name, type (scrum or kanban), and location information.

Sprints

Retrieves all sprints from all Scrum boards accessible to the authenticated account. Sprints are time-boxed iterations used in Scrum methodology. This is a two-step feed: it first retrieves all Scrum boards, then iterates over each board to retrieve its sprints.

• Select Sprints from the Endpoint pulldown menu.
• No additional configuration is required. The feed automatically iterates over all Scrum boards and retrieves their sprints.
• Returned data includes sprint ID, name, state (active, closed, or future), start date, end date, complete date, and the originating board ID.

Only Scrum board sprints are retrieved by this feed. Kanban boards do not use sprints and are not included in this feed's results.

Comments

Retrieves all comments from Jira issues matching a JQL filter. Comments are the discussion threads on Jira issues and contain the conversation history between team members. This is a two-step feed that first retrieves matching issues and then retrieves all comments for each issue. It supports both full and incremental sync strategies.

• Select Comments from the Endpoint pulldown menu.

• Optionally, enter a JQL filter in the Issue JQL Filter field to restrict which issues' comments are retrieved. This uses the same JQL syntax as the Issues feed. The default retrieves comments for all issues:

  • Default (all issues): created+is+not+EMPTY+order+by+id+ASC
  • Specific project: project=MYPROJECT order by id ASC
• For incremental sync, configure the Incremental Sync Lookback Time field to limit the issues iterated to those updated since a given timestamp. This significantly reduces the number of API calls required in incremental runs.
• Returned data includes comment ID, author account ID, created date, updated date, and the comment body in Atlassian Document Format (ADF).

Changelogs

Retrieves the full audit history of changes to Jira issues matching a JQL filter. Each changelog record represents a single field change on an issue, including who made the change, when it was made, and what the field value was before and after the change. This is a two-step feed and supports both full and incremental sync strategies.

• Select Changelogs from the Endpoint pulldown menu.

• Optionally, enter a JQL filter in the Issue JQL Filter field to restrict which issues' changelogs are retrieved:

  • Default (all issues): created+is+not+EMPTY+order+by+id+ASC
  • Specific project: project=MYPROJECT order by id ASC
• For incremental sync, configure the Incremental Sync Lookback Time field to limit the issues iterated.
• Returned data includes changelog ID, the issue it belongs to, author account ID, created timestamp, and an array of items describing each field that changed (field name, field type, from value, and to value).

Changelog data is valuable for auditing workflows, tracking SLA compliance, and analyzing how issues move through your Jira workflow stages over time.

Remote Issue Links

Retrieves all remote links associated with Jira issues. Remote links connect Jira issues to external resources such as Confluence pages, GitHub pull requests, or other web URLs. This is a static two-step feed that retrieves all issues (regardless of date) and then retrieves remote links for each.

• Select Remote Issue Links from the Endpoint pulldown menu.
• No additional configuration is required. The feed automatically iterates over all issues and retrieves their remote links.
• Returned data includes the remote link ID, URL, title, and the parent issue ID.

Issue Boards

Retrieves all issues currently on each Jira board, for every board accessible to the authenticated account. This is a two-step feed that first retrieves all boards and then retrieves the issues associated with each board (returning only the issue ID and key). Use this feed to understand which issues are assigned to which boards.

• Select Issue Boards from the Endpoint pulldown menu.
• No additional configuration is required. The feed automatically iterates over all boards and retrieves their associated issues.
• Returned data includes issue ID, issue key, and the parent board ID.

Project Boards

Retrieves all projects associated with each Jira board, for every board accessible to the authenticated account. This is a two-step feed that first retrieves all boards and then retrieves the project records associated with each board. Use this feed to create a mapping between boards and their associated projects.

• Select Project Boards from the Endpoint pulldown menu.
• No additional configuration is required. The feed automatically iterates over all boards and retrieves their associated projects.
• Returned data includes project details and the parent board ID.

Sync Strategy

The Jira Feeds connector supports two sync strategies, selectable during data source configuration:

• Full Ingest: Retrieves all data from Jira on each run. Supported for all feed types. Use this strategy for reference data feeds (Projects, Fields, Statuses, etc.) or when you need a complete snapshot of Jira data.

• Incremental Sync: Retrieves only records updated since the last successful run. Supported for Issues, Comments, and Changelogs. Use this strategy for high-volume Jira instances where full scans are impractical or slow.

Incremental Sync Configuration

When using incremental sync for Issues, Comments, or Changelogs, the following additional parameters are available:

• Incremental Sync Lookback Time: The starting timestamp for incremental sync runs. Enter the date and time in the format YYYY-MM-DD HH:MM (for example, 2024-01-01 00:00). On the first incremental run, Nexla will fetch records updated on or after this timestamp. On subsequent runs, Nexla automatically tracks the cursor from the last successful run.

Endpoint Testing

Once the selected feed template has been configured, Nexla can retrieve a sample of the data that will be fetched according to the current settings. This allows users to verify that the source is configured correctly before saving.

• To test the current feed configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched and displayed in the Endpoint Test Result panel on the right.

• If the sample data is not as expected, review the selected feed type and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Configure Manually

Jira Feeds data sources can be manually configured to ingest data from any valid Jira Cloud REST API v3 endpoint. Manual configuration provides maximum flexibility for accessing Jira endpoints not covered by the pre-built feed templates or when you need custom API configurations.

The Jira REST API v3 base URL follows the format https://<your-company>.atlassian.net/rest/api/3/. The Jira Agile REST API v1 is available at https://<your-company>.atlassian.net/rest/agile/1.0/. For the complete endpoint reference, see the Atlassian Jira Cloud REST API documentation.

API Method

1. To manually configure this source, select the Advanced tab at the top of the configuration screen.

2. Select the API method that will be used for calls to the Jira Cloud API from the Method pulldown menu. The most common methods are:

   • GET: For retrieving data from the Jira API (used for all standard read operations)
   • POST: For sending data to the API or triggering actions (used for search/JQL endpoints)

API Endpoint URL

3. Enter the URL of the Jira REST API endpoint from which this source will fetch data in the Set API URL field. This should be the complete URL including the protocol (https://) and any required path parameters.

   • Jira REST API v3 example: https://mycompany.atlassian.net/rest/api/3/issue/search
   • Jira Agile API example: https://mycompany.atlassian.net/rest/agile/1.0/board

Ensure the API endpoint URL is correct and accessible with your current credentials. You can test the endpoint using the Test button after configuring the URL. Authentication headers are handled automatically by Nexla based on your Jira Feeds credential configuration and do not need to be added manually.

Date/Time Macros (API URL)

Optional

Optionally, the API URL can be customized using macros—all macros added to the API URL will be converted into values when Nexla executes the API call. Macros are dynamic placeholders that allow you to create flexible API endpoints that can adapt to different time periods or data requirements. This is particularly useful for Jira JQL-based endpoints where you need to filter by date ranges.

Date/time macros are especially useful with Jira JQL search endpoints. For example, you can use {now-7} in a JQL query to fetch issues updated in the last 7 days.

1. To add a macro, type { at the appropriate position in the API URL (within the Set API URL field), and select the desired macro from the dropdown list.

   • {now} – The current datetime
   • {now-1} – The datetime one time unit before the current datetime
   • {now+1} – The datetime one time unit after the current datetime
   • custom – Datetime macros can reference any number of time units before or after the current datetime—for example, enter (now-4) to indicate the datetime four time units before the current datetime

2. Select the format that will be applied to datetime macros from the Date Format for Date/Time Macro pulldown menu. This format will be applied to the base datetime value of the macro—i.e., the value of {now} in {now-1}.

3. Select the datetime unit that will be used to perform mathematical operations in the included macro(s) from the Time Unit for Operations pulldown menu—for example, for the macro {now-1}, when Day is selected, {now-1} will be converted to the datetime one day before the current datetime.

Lookup-Based Macros (API URL)

Optional

Column values from existing lookups can also be included as macros in the API URL. Lookup-based macros allow you to reference data from previously configured data sources or lookups, enabling dynamic Jira API endpoints that can adapt based on existing data—for example, iterating over a list of Jira project keys retrieved from another source.

Lookup-based macros are useful when you need to create Jira API endpoints that reference specific IDs, project keys, or other parameters from other data sources in your Nexla environment.

1. To include a lookup column value macro, select the relevant lookup from the Add Lookups to Supported Macros pulldown menu.

2. Type { at the appropriate position in the API URL, and select the lookup column-based macro from the dropdown list. Lookup-based macros are automatically populated into the macro list when a lookup is selected in the Add Lookups to Supported Macros pulldown menu.

Path to Data

Optional

If only a subset of the data returned by the Jira API endpoint is needed, you can designate which part of the response should be included in the Nexsets produced from this source by specifying the path to the relevant data within the response.

For example, the Jira Issue Search API (/rest/api/3/search) returns a JSON object containing the array of issue records under the key issues, along with metadata fields like total, startAt, and maxResults. By entering $.issues[*] as the path to data, you configure Nexla to treat each element of the issues array as a separate record.

Path to Data is essential when working with Jira API responses that contain nested structures. Most Jira list endpoints return records nested within a named property (such as issues, values, or boards) alongside pagination metadata.

• To specify which data should be treated as relevant in responses from this source, enter the path to the relevant data in the Set Path to Data in Response field.

  • For responses in JSON format, enter the JSON path that points to the object or array that should be treated as relevant data. JSON paths use dot notation (for example, $.issues[*] to access an array of issues, or $.values[*] to access a paginated values array).
  Path to Data Examples for Jira:

  • Issues search endpoint: $.issues[*]
  • Paginated list endpoints (projects, boards, sprints): $.values[*]
  • Static list endpoints (fields, statuses, resolutions): $[*]

Autogenerate Path Suggestions

Nexla can also autogenerate data path suggestions based on the response from the API endpoint. These suggested paths can be used as-is or modified to exactly suit your needs.

• To use this feature, click the Test button next to the Set API URL field to fetch a sample response from the Jira API endpoint. Suggested data paths generated based on the content and format of the response will be displayed in the Suggestions box below the Set Path to Data in Response field.

• Click on a suggestion to automatically populate the Set Path to Data in Response field with the corresponding path. The populated path can be modified directly within the field if further customization is needed.

  

Metadata

If metadata is included in the Jira API response but is located outside of the defined path to relevant data, you can configure Nexla to include this data as common metadata in each record. This is useful when you want to preserve pagination metadata or request context alongside your Jira records.

For example, the Jira Issue Search API response includes fields like total (total number of matching issues), startAt, and maxResults at the top level of the JSON object, outside the issues array. If you have specified $.issues[*] as the path to data, you can specify a metadata path to capture these fields and include them with each issue record.

Metadata paths are particularly useful for preserving Jira API response context like total record counts, pagination parameters, or request timestamps that apply to all records in the response.

• To specify the location of metadata that should be included with each record, enter the path to the relevant metadata in the Path to Metadata in Response field.

  • For responses in JSON format, enter the JSON path to the object or array that contains the metadata (for example, $ to capture the top-level response object as metadata).

Request Headers

Optional

• If Nexla should include any additional request headers in API calls to this source, enter the headers and corresponding values as comma-separated pairs in the Request Headers field (for example, header1:value1,header2:value2).

  You do not need to include Authorization or Content-Type headers. These are handled automatically by Nexla based on your Jira Feeds credential configuration. Additional headers may be needed for specific Jira API scenarios such as API version pinning or custom Accept headers.

Endpoint Testing

After configuring all settings for the selected endpoint, Nexla can retrieve a sample of the data that will be fetched according to the current configuration. This allows users to verify that the source is configured correctly before saving.

• To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched and displayed in the Endpoint Test Result panel on the right.

• If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Save & Activate the Source

1. Once all of the relevant steps in the above sections have been completed, click the Create button in the upper right corner of the screen to save and create the new Jira Feeds data source. Nexla will now begin ingesting data from the configured Jira feeds and will organize any data that it finds into one or more Nexsets.