Application Operations and Planning

Integration Types

Full Featured vs Webhook Indexing

Most users choose either Full Featured or Webhook Indexing integrations. Full Featured integrations create active two-way connections, while Webhook Indexing integrations create one-way passive connections.

Consider these factors when choosing:

1. Your company policy regarding code cloning
2. Whether your Git server is private or public

Full Featured integrations are recommended for most users because they provide access to all features. If your Git server is behind a firewall or proxy, you can still use this integration type by allowlisting our IPs and ensuring your Git service URL is publicly routable. See Allowlist – GIJ Cloud for details.

Full Featured integrations require GIJ to clone your repositories to provide Code Compare and Code Diff functionality directly from Jira. Repositories are cloned to AWS storage in a directory assigned specifically to your installation. All traffic and data is encrypted in transit and at rest. Visit our Security and Trust page for an overview of security measures.

Webhook Indexing integrations accommodate users with security restrictions around code cloning, or users with self-hosted Git servers behind firewalls that cannot be made publicly routable. See the Webhook Indexing Explainer for details on how this works. This integration type has a limited feature set because it relies on webhook metadata rather than direct repository access.

See our Feature Matrix for a detailed breakdown of features by integration type.

Plain Git Connections

If you don’t use a major Git service (GitHub, GitLab, Azure DevOps, Bitbucket, AWS), GIJ supports plain Git connections to individual repositories. See the Feature Matrix linked above for details on plain Git connection limitations.

Indexing Behavior

Now that you understand integration types, let’s examine how Git Integration for Jira indexes updates from your repositories.

Full Featured Integrations

Full Featured integrations go through two stages of indexing: initial indexing (happens once) and normal indexing.

First Time Indexing

Initial indexing occurs only when you first add an integration to GIJ or add a new repository to an existing integration. This phase includes two actions:

1. Clone all repositories (or the newly created repository)
2. Scan the entire Git history for each repository, searching for Jira issue references

This scan links any Git data that previously referenced Jira issues, providing comprehensive historical Git data in Jira. Because these operations are more intensive, initial indexing takes longer than subsequent indexes. Total index time varies based on repository Git history length, number of branches and pull/merge requests, and number of repositories in the integration.

Normal Indexing Operations

After initial indexing completes, the application automatically indexes your Git repositories periodically based on an adaptive timer. Index frequency varies based on how often changes are detected in each repository, but most active repositories index every 20 minutes or so. The time required to complete all indexing tasks also affects frequency.

For a comprehensive explanation of the indexing process, see Classic Indexing Explainer.

Indexing Triggers

We recommend using Indexing Triggers alongside your integrations. These triggers are webhooks sent from your repositories whenever updates occur. When GIJ receives the webhook, it automatically indexes that repository outside the normal timer, enabling near real-time updates.

Webhook Indexing

Despite the name, Webhook Indexing integrations don’t actually index repositories. Since this is a one-way passive integration, GIJ never clones, scans, or indexes your repositories. Instead, it relies on metadata in the webhooks to update Jira issues.

With Webhook Indexing:

• No specific code change information is sent
• No repository information is sent
• Repository records are added after webhooks are received

GIJ only updates Jira issues when it receives webhooks containing Jira issue keys. There is no periodic or scheduled indexing, so all changes update in near real time by default.

Integration Structure Planning

Now that you understand what to expect with GIJ, take time to evaluate how to structure your integrations:

1. Total number of repositories you want to connect to Jira

   • More connected repositories make management more challenging, especially when using project associations
   • More repository connections increase the likelihood of rate limiting issues

2. Repository structure in your Git services

   • Are repositories organized by organization/group, or is everything in a single group/org?
   • More structured repositories make integration creation easier

Consider creating multiple integrations to the same Git service, each connecting to a different org/group, instead of one large integration containing all repositories. If you have fewer than 100 repositories, this may not be necessary. If you have more than 100 and want to limit visibility between Jira projects, breaking them into multiple integrations makes management easier.

The best approach is usually to create one integration per org/group, keeping each integration under 2,000 repositories. If a group/org has more than 2,000 repositories, create multiple integrations to that same org/group to keep each under 2,000 repositories. You can do this by manually selecting repositories in the UI or by applying Custom API Path and/or JMESPath Filtering.

Rate limiting can become an issue for large instances with many repositories or repositories with long, complex Git histories with many branches and pull/merge requests. To address this, generate multiple service accounts on your Git service and spread authentication across different accounts. This distributes API calls across more accounts and over longer periods, helping avoid rate limits.

NEXT Integration Creation and Post Integration Config

PREVIOUS Getting Started

Last updated: December 2025