This changelog is the source of truth for all changes to the Forge platform that affect people developing Forge apps.
See what's next for Forge on our platform roadmap.
We're excited to share that Forge, our app development platform for Atlassian cloud apps, is now generally available. You can rely on Forge's hosted infrastructure, storage, and FaaS functions to support apps in production; all of which are backed by Atlassian's operational readiness. Learn more about building the next Marketplace hit with Forge.
Note that some functionality in Forge remains in beta while we're still making changes that may break your apps. Learn more about the current functionality in beta.
Forge customer-managed egress and remotes are now available through Forge’s Early Access Program (EAP). This capability lets admins control which external domains and remotes a Forge app can connect to, and configure those connections per installation. This approach is useful for apps that need to load data from customer-defined URLs, without declaring every possible destination up front in the manifest.
To join the EAP, complete this sign-up form.
We've added new methods to the webTrigger API from @forge/api that allow you to query and delete previously created web trigger URLs.
webTrigger.queryUrls() — Retrieve all web trigger URLs for your app, optionally filtered by module key
webTrigger.deleteUrl() — Delete a specific web trigger URL
For implementation details and examples, see the Web trigger runtime API documentation.
Support for dynamically retrieving the list of supported models is now available in Forge LLMs. The new list function in the @forge/llm SDK lets apps fetch the latest list of models, returning a response like:
1
2
3
4
5
6
7
8
9
10
11
12
{
"models": [
{
"model": "claude-sonnet-4-20250514",
"status": "active"
},
{
"model": "claude-opus-4-20250514",
"status": "deprecated"
}
]
}You can filter on the status field to ensure your app always uses an active model and avoid breaking changes when a model is removed.
Forge LLMs remain in Early Access (EAP). Due to high demand, participation is limited. To request access, join the waitlist here.
For implementation details, refer to the documentation here.
You can now migrate a Connect Jira Issue Field module to Forge's custom field module. The functionality is now available for String, Number and Read-only fields.
See https://developer.atlassian.com/platform/adopting-forge-from-connect/migrate-jira-issue-fields/ for more details.
Forge app REST APIs let your app expose its own HTTP endpoints so that external systems can call your app code running on Forge.
These Forge app REST APIs are secured with developer-defined scopes and use 3LO (OAuth 2.0) for authentication and authorization. You define the endpoints in your app manifest using the apiRoute module.
This capability is currently in Preview and is available for Jira and Confluence Forge apps. This is currently not available in Isolated Cloud.
To learn how to expose REST APIs in your Forge app, see Expose Forge app REST APIs. For a step-by-step tutorial on configuring a 3LO integration to access exposed REST APIs, see Access REST APIs exposed by a Forge app.
Forge embedded macros are now available through Forge’s Early Access Program. To join the EAP, please complete this sign-up form.
Forge bodied macro apps can now render embedded Forge macro apps through the AdfRenderer component (UI Kit) and the view.createAdfRendererIframeProps method from @forge/bridge (Custom UI).
For more information, see the updated documentation for Forge rich-text bodied macros.
A new RFC is ready for review at: https://community.developer.atlassian.com/t/rfc-125-ui-modification-for-forge-custom-fields/98439
A new RFC is ready for review at: https://community.developer.atlassian.com/t/rfc-124-evolving-the-marketplace-trust-program/98418
Jira global background scripts are now available in Preview. This feature enables you to add an invisible container that coordinates data and behavior across all pages in Jira, enabling advanced integrations and automations.
We’re releasing this feature in preview to gather feedback and help you prepare for upcoming changes. You can use global background scripts in production environments during the preview period.
For more information, see Jira global background scripts (Preview)
As announced in July 2025, a number of glyphs for the Icon component will now be removed.
A new RFC is ready for review at: https://community.developer.atlassian.com/t/rfc-123-csm-extensibility-on-forge/98412
The avi:jira:created:issue event now includes an clonedFrom field if the issue was created through the “Clone” operation. This field contains the ID and key of the original issue.
Support for Claude Opus 4.5 model is now available in Forge LLMs. This is in addition to the already supported Claude Opus 4 and Claude Opus 4.1 models.
Also note that Claude Opus 4 has been marked as deprecated and support will be removed in February 2026.
Forge LLMs remain in Early Access (EAP). Due to high demand, participation is limited. To request access, join the waitlist here.
For the exhaustive list of supported models, refer to our documentation here
We announced in a previous changelog that we would be changing the Forge user invocation rate limits from 1,200 requests per minute (RPM) to 20 requests per second (RPS). In response to customer feedback, we’ve decided not to implement this change. Invocation rate limits will continue to be 1,200 per one-minute fixed window.
These invocation rate limits are applied specifically by the Forge platform, and unrelated to the upcoming Jira/Confluence point-based rate limits. For more information, see https://developer.atlassian.com/platform/forge/limits-invocation/.
This fix will be rolled out on Jan 28, 2026 across all Jira Cloud instances.
We fixed bugs that caused the Issues Match REST API and webhooks to evaluate JQL queries differently than the standard Issue Navigator. JQL expressions using EMPTY or != with issue properties or the "Epic Label" field now return consistent results across all Jira Cloud features.
This fix is not backward-compatible. Integrations that relied on the previous behavior may see different results from the Match API or different events triggering webhooks.
Related tickets: JRACLOUD-96922, JRACLOUD-97120
JQL expression | Previous behavior (Match API/webhooks) | New behavior |
|---|---|---|
| Did not match issues where the field was unset | Matches issues where the field is unset |
| Matched correctly | No change |
| Did not match issues where the field was unset | Matches issues where the field is unset |
| Matched all issues, including those where the field was unset | Only matches issues where the field is set |
| Matched correctly | No change |
| Matched all issues, including those where the field was unset | Only matches issues where the field is set |
This applies to both issue properties (for example, issue.property[key].path) and the "Epic Label" field.
JQL expression | Previous behavior | New behavior |
|---|---|---|
| Returned issues where the property was never set | Only matches issues where the property exists and its value is not |
You may see differences in:
The issues returned by POST /rest/api/3/match when using JQL with EMPTY or != on issue properties or "Epic Label"
The events that trigger webhooks using JQL filters with these operators and fields
Review any JQL used in webhook filters or Match API requests that contains:
EMPTY operators with issue properties or "Epic Label"
!= comparisons with issue properties
Best practices:
Goal | Recommended JQL |
|---|---|
Check if a field is set |
|
Check if a field is not set |
|
Specific scenarios:
To find issues where a property is either not set OR has a different value:
1
issue.property[key].path != "a" OR issue.property[key].path IS EMPTYTo find issues where a property is set AND has a different value:
1
issue.property[key].path != "a" AND issue.property[key].path IS NOT EMPTYTest critical webhook flows and integrations that use the Match API to confirm they behave as expected.
Rate this page: