Forge SDK Method for Triggering Jira Automation Webhooks

Forge
, , ,
1

Problem Statement

Our Forge app (NASA Standup) needs to trigger Jira Automation rules when a standup meeting completes. Currently, the only way to do this is by calling
https://api-private.atlassian.com/automation/webhooks/{webhook-id} using fetch(), which requires declaring external.fetch permissions.

The paradox:

  • api-private.atlassian.com is Atlassian’s own infrastructure
  • The data never leaves Atlassian’s ecosystem
  • Yet this disqualifies the app from “Runs on Atlassian” eligibility because Forge treats it as “external egress”

Current Implementation

We POST to Jira Automation webhooks with this structure:

const webhookResponse = await fetch(webhookUrl, {
method: ‘POST’,
headers: {
‘Content-Type’: ‘application/json’,
‘X-Automation-Webhook-Token’: webhookSecret,
},
body: JSON.stringify({
issues: [‘PROJ-123’, ‘PROJ-456’],
data: {
participant: ‘atlassian-account-id’,
comments: { ‘PROJ-123’: ‘Comment text’ }
}
}),
});

Security measures we’ve implemented:

Use Case

Users configure automation rules that trigger Jira Automation workflows when a standup completes:

  • Create summary issues with flagged items
  • Update issue statuses based on standup comments
  • Send notifications via Jira Automation’s integrations (Slack, Teams, etc.)

This is a valuable feature that connects our app with Atlassian’s first-party automation platform.

Proposed Solutions

Option 1: Exempt api-private.atlassian.com for Automation Webhooks

Allow external.fetch to api-private.atlassian.com/automation/webhooks/* without disqualifying apps from “Runs on Atlassian”, since:

  • It’s Atlassian-owned infrastructure
  • It’s for a first-party Atlassian feature
  • Data stays within Atlassian’s ecosystem

Option 2: New Forge SDK Method

import { automation } from ‘@forge/api’;

await automation.triggerWebhook({
webhookId: ‘webhook-uuid’,
webhookSecret: ‘secret-token’,
payload: { issues: [‘PROJ-123’], data: { … } }
});

This would be similar to how requestJira() and requestConfluence() work - internal Atlassian API calls that don’t require external.fetch declarations.

References

Additional Context

We understand from documentation that “Atlassian is currently not able to allow-list Atlassian domains for other types of egress because this can lead to cross-tenant access to
data.” However, Jira Automation webhooks are inherently tenant-scoped - users create webhooks within their own Jira instance, and the webhook ID/secret combination ensures
tenant isolation.

We’d be happy to provide more technical details or discuss alternative approaches.

2 Likes
2

Hi Amr,

I just want to add that I’m facing exactly the same problem.

In my case, I had to declare external.fetch in the manifest only because of calls to https://api-private.atlassian.com/automation/webhooks/.... As a result, my app is no longer eligible for the “Runs on Atlassian” badge — even though:

  • The request goes to Atlassian-owned infrastructure
  • The data never leaves Atlassian’s ecosystem
  • The webhook is tenant-scoped and protected by ID + secret

From an architectural and security perspective, this does not feel like true “external egress”. It’s a first-party Atlassian platform integration.

Because of this, I strongly support one of the following:

  1. A dedicated Forge SDK method (e.g. automation.triggerWebhook()), similar to requestJira() or requestConfluence(), which would treat this as an internal Atlassian call.

or

  1. Exempting api-private.atlassian.com/automation/webhooks/* from disqualifying Runs on Atlassian eligibility, since it’s clearly Atlassian infrastructure and not third-party data egress.

Right now, we’re in a paradoxical situation where integrating with Atlassian’s own Automation product penalizes apps under the Runs on Atlassian model.

A first-class solution would make a big difference for Forge apps that aim to stay fully aligned with the platform’s hosting and security model.

+1 from my side :+1:

3

We make a lot of automation webhook calls from our apps, and a Forge/REST API to call directly would be very helpful for us as well.

Even better if they find a way to not need the customers to copy paste and for us to encrypt and store a token. The trigger automation rule should just need the rule ID. If the calling app is already authenticated as inside the site then the token is redundant.

+1 for us.

1 Like