Why Jira Hooks for Bitbucket Cloud is not eligible for the Runs on Atlassian program

Overview

The Runs on Atlassian program certifies that a Forge app operates fully within Atlassian’s infrastructure trust boundary.

Jira Hooks for Bitbucket Cloud is intentionally not eligible for this program because the product architecture requires:

• communication with external Atlassian tenant APIs

• externally accessible integration endpoints

Both capabilities are essential product features and are also important for the overall developer experience. Removing them would fundamentally change the feature set and usability of the application.

What Runs on Atlassian requires

According to the official Atlassian documentation:

• Forge apps must not egress data to systems outside Atlassian infrastructure

• Forge apps must not expose public inbound communication channels that bridge external systems into the Forge runtime

For reference, see:

• https://developer.atlassian.com/platform/forge/runs-on-atlassian/

• https://developer.atlassian.com/platform/forge/runtime-egress-permissions/

Reason 1 – External API communication

The application declares the following permission in the manifest.yml:

The application configuration declares external backend fetch permissions for *.atlassian.net domains and registers a commit-validation-trigger webtrigger with dynamic responses enabled.

At runtime, the application communicates with Jira and Bitbucket REST APIs on customer-specific *.atlassian.netdomains.

This communication is required to:

• resolve Jira issue keys

• validate Jira issue states via JQL

• access repository and pull request information

• evaluate compliance rules during pull request validation

Although these endpoints belong to Atlassian, the requests are executed dynamically against tenant-specific URLs outside the Forge runtime boundary. This constitutes network egress and therefore disqualifies the app from the Runs on Atlassian program.

Reason 2 – Usage of the webtrigger module

Registered webtrigger

The application registers the following Forge module:

The application configuration declares external backend fetch permissions for *.atlassian.net domains and registers a commit-validation-trigger webtrigger with dynamic responses enabled.

This module exposes a publicly reachable HTTPS endpoint.

The endpoint is used by:

• local git hooks

• CI/CD pipelines

• external automation systems

These systems submit commit information to Jira Hooks for Bitbucket Cloud in order to validate commits before they are pushed or merged.

Why the webtrigger exists

The webtrigger enables one of the core product capabilities:

• pre-push commit validation

• pre-receive style enforcement

• early developer feedback before code reaches the repository

The endpoint receives structured commit payloads containing:

• branch names

• commit hashes

• commit messages

• author information

The Process Guardian validates this information against configured compliance rules and returns a structured validation result.

This allows teams to detect invalid commit messages or missing Jira issue references before the code reaches Bitbucket.

Without this functionality, validation would only occur during pull request merge evaluation, which is too late for many compliance workflows.

Why webtrigger responses prevent Runs on Atlassian eligibility

In general a static webtrigger would be more compatible with the Runs on Atlassian requirements. However, it would only be able to return predefined responses and could not provide context-specific validation results. As a result, developers would receive generic feedback without details about failed commits, violated rules, or remediation steps. To provide actionable validation feedback and a better developer experience, Jira Hooks for Bitbucket intentionally uses dynamic webtrigger responses. This architectural decision makes the application ineligible for the Runs on Atlassian program but preserves an essential product capability.

A static webtrigger would be more compatible with the Runs on Atlassian requirements. However, it would only be able to return predefined responses and could not provide context-specific validation results. As a result, developers would receive generic feedback without details about failed commits, violated rules, or remediation steps.

So without dynamic responses:

• developers would not know which commit failed

• CI systems could not react correctly

• the feature would lose its practical usability

The dynamic response is therefore not a technical preference but a functional product requirement.

Summary

Key takeaway

Jira Hooks for Bitbucket Cloud is intentionally not eligible for the Runs on Atlassian program because the product requires external Atlassian API communication and public webtrigger endpoints to provide real-time, synchronous compliance validation for git hooks, CI pipelines, and pull request workflows.