Our most popular integration.

Cardagraph x Atlassian.

Deep Integration Experience

Our team has decades of experience is these integrations and data sets.

Reliable Support

Dedicated technical assistance ensuring smooth operations.

Proven Results

Track record of driving success and delivering exceptional outcomes.

Trusted Security

Robust measures safeguarding your data and ensuring confidentiality.

Let's get to it

We do the work.

Access to your company’s production Jira server is required for Cardagraph functionality. Most of the data is pulled from the on-prem system into Cardagraph. There is an option for a Cardagraph user to initiate the pushing of Epics/Tasks back into the system.

Below you will find information that is often requested by the IT professionals at your company who will assist you in getting Cardagraph the needed access to your Jira. It is wise to involve them early and often as we get data flowing. Often authentication, authorization, and network changes must be approved by review committees before work can begin. The more you understand this process (or have a project manager helping) the more smoothly things will go.

We at Cardagraph are ready to help and encourage throughout the process.

JIRA←→Cardagraph Data Flow

The requests to and responses from your Jira Server’s REST API provide the data and functionality Cardagraph needs.

The data flow is largely FROM Jira Server TO Cardagraph is initiated by the Cardagraph servers on a daily-refresh schedule. Access to the Jira server itself is controlled by permissions granted the user who is associated with the PAT, HTTP-basic, or OAuth2 grantor.

The only data flowing TO Jira Server FROM Cardagraph (initiated by a user in Cardagraph) is when a user opts to push a “project” created in Cardagraph back to a Jira project as a new issue.

Once the Jira data arrives on Cardagraph servers we transform it into our proprietary data structures, analyze it and produce the forecasts that your users consume through the Cardagraph web application.

JIRA REST API auth and permissions for Cardagraph

Cardagraph requires admin-level access to reach the data necessary for configuration and analyses we perform. We will need to coordinate with your Jira admin throughout the integration phase on which auth method to use.

Jira provides several authentication methods for API access: PAT, HTTP-basic, and OAuth2. All PAT, tokens and other sensitive information are encrypted before storing and also encrypted at-rest in Postgres.

PAT: a user with sufficient permissions can generate a personal access token (PAT) that is provided to Cardagraph through a web form and encrypted before storing in Postgres.

HTTP-basic: a (new and non-sso) Jira service user can be given for HTTP-basic username/password authentication.

OAuth2: requires an identity provider (can be Jira, but can be another like Azure Active Directory) and a user with sufficient permissions to authorize the scope request for Cardagraph unattended access to the features we need. We will also need to coordinate with admins of your identity provider for this option.

Network Map

Without a Firewall, Cardagraph API requests will arrive on the Jira server directly from Heroku/AWS IP ranges.

If your company employs a firewall to protect your Jira server from public view, we will also need to seek approval and work closely with your network security team to gain access to your server.

The two most common approaches are: (1) authorizing requests from known IP addresses to be routed through the firewall to your server where the requests are checked by the selected Jira authentication method described above; and (2) providing VPN access credentials to Cardagraph that will be employed on a Cardagraph VPN proxy through which requests to your server will be sent.

The network maps for both of these scenarios are available at your request.

The Cardagraph Tech Stack

Cardagraph is hosted on Heroku’s Common Runtime configuration using their heroku-22 stack (the current default and supported through April 2027 with Ubuntu 22.04LTS) hosted in the US region. Heroku manages the stack inside of an AWS EC2 instance. The IP addresses are, therefore, described by AWS at this page.

The Cardagraph website runs with horizontally scalable web and worker servers.

We utilize the Heroku Postgres addon as our database, described here.

Our Postgres server is hosted in the US region and is currently on version 14.11.

Plan with accurate timelines you can trust and stop running blind.