Integrating External Services in Atlassian Forge — Without Losing the “Runs on Atlassian” Eligibility

Forge
, , ,
8

Just tested this behavior — when a Forge app is uninstalled, the existing static web trigger URLs become invalid.

However, if the app is reinstalled, the same static web trigger URL remains valid again (no rotation) and starts working as before.

When calling a trigger of an uninstalled app, Forge responds with:

{
  "statusCode": 424,
  "response": {
    "timestamp": "2025-10-14T14:54:10.393+00:00",
    "path": "/x1/upHs7HD4zoPLigGLOgN3eFGiL2U",
    "status": 424,
    "error": "Failed Dependency",
    "requestId": "7929e69f-1088608"
  }
}

The 424 response is not a reliable way to detect outdated trigger URLs, since Forge can return the same code for any unexpected error, not only when the app is uninstalled.

Two possible workarounds:

  1. Error-based detection — handle requests in a try/catch and treat persistent 424 responses as “potentially uninstalled”. If this status persists for a while (or after a few retries), mark the Forge installation as inactive.
  2. Installation check — query the Forge installation list via GraphQL or the CLI (forge install list --json) to verify that the installation still exists.

The first approach is simpler and works automatically during normal request handling.

@rmassaioli It would be great if Atlassian returned a more specific error (e.g., 410 Gone) when the app has been uninstalled — that would make uninstalled app detection logic much clearer.

3 Likes