Approve egress to your endpoint

Forge requires Jira admin consent for every external host the app sends data to. The first time you save a webhook pointing at api.example.com, the admin sees an approval dialog. After that, the host is allow-listed for the whole app — no approval needed for any other webhook to the same host.

This is a Forge platform behaviour, not a Webhooks Pro choice. It applies to every Forge app that makes outbound network calls.

What approval looks like

When you click Save on a webhook with a brand-new destination host, Forge intercepts the save and pops up an approval dialog showing:

The destination host (e.g. hooks.slack.com).
The Jira admin must click Allow for the save to complete.

If the admin clicks Allow, the save completes and the webhook is created.

If the admin clicks Deny or closes the dialog, the save fails with a clear message ("Egress to hooks.slack.com was not approved"), and the webhook is not created.

Per host, not per webhook

Approval is keyed on the destination host (the part between :// and the first /):

Webhook URL	Approved as	Same host?

Webhook URL	Approved as	Same host?
`https://api.example.com/v1/jira`	`api.example.com`	—
`https://api.example.com/v2/anything`	`api.example.com`	✅ no new approval needed
`https://other.example.com/jira`	`other.example.com`	❌ separate approval
`https://api.example.com:8443/jira`	`api.example.com:8443`	❌ different port = different host

Once approved, every webhook in this Webhooks Pro install can reach that host — including future webhooks created weeks later.

Who sees the dialog

The currently signed-in Jira admin at the moment of save. Non-admins shouldn't be on the Webhooks Pro pages in the first place — but if they somehow trigger a save, the platform still shows the dialog and requires the consent of an admin account.

Re-approval and revocation

Re-approval is not needed for an already-approved host, ever. The approval persists across app upgrades.
Revoking a previously approved host: open Settings (⚙️) → Marketplace apps → Manage apps → Webhooks Pro → Permissions (location varies slightly across Jira UI versions). Atlassian shows the list of hosts the app has been granted egress to; remove an entry to revoke. After revocation, future deliveries to that host will fail with a network error until you re-approve.

Webhooks Pro and the manifest

The app's manifest.yml declares external.fetch.backend: ["*"] — i.e., the app can talk to any host. But "can" only means "can ask the admin for permission". The actual gate is the per-host runtime approval above.

Why declare * rather than a fixed list? Because the destinations are configured by the customer at runtime — the vendor doesn't know in advance whether you'll be sending to Slack, Datadog, an internal Lambda, or a self-hosted webhook receiver.

Common pitfalls

Symptom	Cause	Fix

Symptom	Cause	Fix
Save fails with "egress not approved" and you never saw a dialog	Pop-up blocker, or you switched Jira tabs before the dialog appeared	Stay on the Save click; allow pop-ups for `*.atlassian.net`; click Save again.
Same dialog every time you save	You're using a different host each time (e.g. `https://example.com` vs `https://www.example.com`)	Pick one canonical host and stick with it.
Worked yesterday, fails today	Host approval was revoked, or the destination URL was edited to a different host	Re-approve via Settings (⚙️) → Marketplace apps → Manage apps, or restore the original URL.
Test webhook URL works (e.g. `webhook.site`) but production URL fails	Test was approved for one host; production is a different host	Save the production webhook — the dialog will appear for the new host.

For deeper diagnosis when delivery fails after approval, see Status code 0 and network errors.