This page contains announcements and updates for developers from various products, platforms, and programs across Atlassian. It includes filter controls to make it easier to only see updates relevant to you.
To ensure you don’t miss any updates, we also provide RSS feeds. These feeds will take on any filters you applied to the page, and are a standardized way of keeping up-to-date with Atlassian changes for developers. For example, in Slack with the RSS app installed, you can type /feed <FEED URL> in any channel, and RSS updates will appear in that channel as they are posted.
We’ve clarified the state and approval status transitions supported for app listings and app version listings in the Marketplace v3 API documentation, detailing which changes are allowed via API and which must be done in the Marketplace UI.
These are documentation‑only clarifications that align the docs with existing behavior.
Endpoint: PUT /rest/3/product-listing/{productId}
We’ve clarified how the state field can be used via this endpoint:
The only supported state transition via this API is PRIVATE → PUBLIC.
You can use this API to change your app listing state only from PRIVATE to PUBLIC.
Any other state changes (for example, to ARCHIVED, DELETED, or READY_TO_LAUNCH) are not supported by this API and must be done in the Atlassian Marketplace user interface.
The app listing endpoint reference and UpdateProductListingV3Request schema descriptions have been updated to reflect these restrictions.
Impact: You can safely use this endpoint to publish an existing private listing, but you should continue to use the Marketplace UI for all other listing state changes.
Endpoint: PUT /rest/3/app-software/{appSoftwareId}/versions/{buildNumber}/listing
We’ve clarified how approvalStatus and state behave for app version listings:
Approval status: approval status transitions are not allowed via this API.
State restrictions: changing a version from PUBLIC to PRIVATE is not allowed when that version is the only public version of the app.
The app version listing endpoint docs and UpdateAppSoftwareVersionListingV3Request schema descriptions now document these rules explicitly.
Impact: You can continue to use this endpoint to manage version listing details, but must rely on the Marketplace UI and the review workflow for approval changes, and you cannot hide the only public version of an app via API.
If you use PUT /rest/3/product-listing/{productId}:
Ensure your integration only attempts a PRIVATE → PUBLIC state transition.
Use the Marketplace UI for all other listing state changes.
If you use PUT /rest/3/app-software/{appSoftwareId}/versions/{buildNumber}/listing:
Do not attempt to change approvalStatus via this API.
Avoid attempting PUBLIC → PRIVATE if the version is the only public version of the app.
Handle unsupported transitions via the Marketplace UI. Requests that attempt these transitions will continue to return validation errors.
Note: The changes will roll out in stages, starting Mar 16, 2026. Initially, a small percentage of partners will have access, with phased expansion to all partners expected within two weeks.
We've introduced a new asynchronous bulk API that allows Jira administrators to pin or unpin Forge app issue panels to multiple projects in a single request — processing up to 1,000 projects at once.
For app developers: Integrate this API into your Forge app to give Jira admins a centralized view for managing issue panel visibility across projects. For full API details, see: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-panels/#api-rest-api-3-forge-panel-action-bulk-async-post
Forge embedded macros are now available in Preview.
Forge apps can now render embedded Forge bodied macros through the AdfRenderer component (UI Kit) and the view.createAdfRendererIframeProps method from @forge/bridge (Custom UI).
Update to the latest version of @forge/bridge with npm install @forge/bridge@latest
For more information, see documentation.
Following the EAP release, Custom Metrics is now generally available.
Custom metrics let you track specific events, actions, and measurements within your Forge app. This helps you monitor business KPIs and instrument critical paths in your app code.
Customers can enable or disable custom metrics access from admin.atlassian.com. The access status—enabled or disabled—now appears for each installation on the Installations page in the developer console. The default access is enabled for all installations.
Custom metrics are also available via the export app metrics API. For more information about metrics, see Monitor custom metrics.
We’ve introduced a platform-level URL persistence and redirect feature for apps migrating from Connect to Forge. Jira and Confluence will now accept legacy Connect URLs (including full path, query parameters, and fragments) and transparently redirect them to the corresponding Forge app module. For more information on how it works, please see the documentation here.
Bitbucket Data Center and Server 8.19.29, 9.4.18, and 10.2.1 bug fix releases are available now!
To see the issues resolved in these bug fix releases, go to:
Get the latest LTS bug fix release
We have now added the ability to use the following as dynamic modules, available under Forge’s Early Access Program (EAP):
To start testing, sign up for the EAP here.
We’re introducing support for multiple field contexts per project in Jira Cloud. This allows more than one context to exist for a single project across different issue types, and multiple default values to be set for different issue types within a single context.
As part of this change, the existing REST APIs for managing context default values are being deprecated and will be replaced by new APIs that support multiple default values.
Deprecated APIs:
Deprecation Timeline:
July 2026: New default values REST APIs introduced. Existing "Get" API will return an error for contexts with multiple defaults; "Set" API will override all issue types in a context.
October 2026: Existing default values APIs will be removed.
What you need to do:
If you use the affected APIs, plan to migrate to the new REST APIs before October 2026.
You can now nominate genuine migration blockers or major customer‑impact risks via the “Request review” flow on FRGE issues.
This flow will allow us to triage and assess requests to address remaining blockers to Forge migration before Connect end of support in December 2026. We’ll review requests over 3 monthly cycles, then freeze decisions.
Please review for existing tickets before creating new FRGE tickets. You may also review the announcement.
We’ll publish the outcomes of these decisions on the following pages:
Approved / available capabilities:
https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-forge-equivalences/connect-forge-capabilities-available/
Not‑available capabilities (including rejected requests):
https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-forge-equivalences/connect-forge-capabilities-notavailable/
We’ve upgraded the Lucene search library from version 7.3 to 10.3.1 for the upcoming Jira 12 release. This upgrade improves search performance and accuracy but includes breaking API changes and requires a full reindex.
Key changes:
Full reindex required
API updates
Configuration cleanup
Label ordering fix
The KVS and Custom Entity Store now allow you to batch multiple delete and get operations. These new capabilities are included in the latest version of the @forge/kvs package.
Bitbucket Data Center 10.2 is available for upgrade!
Get the most out of handy features, such as responsive pull requests on mobile and merge queues!
You can now generate Atlassian API tokens that are scoped to only the permissions required for the Forge CLI. Update to Forge CLI version 12.15.0 or later to start using scoped tokens.
Previously, Forge CLI relied on tokens with broad permissions. Scoped tokens help you follow security best practices, apply the principle of least privilege in CI/CD pipelines, and reduce the blast radius of a compromised token.
What you need to do
Update your Forge CLI to version 12.15.0 or later.
Run forge login and follow the instructions to create a Forge scoped API token.
Existing unscoped tokens will continue to work.
The Forge Model Context Protocol (MCP) Server is now generally available. This remote MCP server enables Forge app developers to use coding agents with up-to-date Atlassian Forge and Cloud documentation, including markdown-based guides, module catalogs, and manifest references. The Forge MCP Server also offers a search feature for Forge reference documentation and implementation patterns. These features are designed to streamline Forge app development in AI-powered workflows.
This release packs performance, reliability and search relevance improvements. We invite you to try the Forge MCP Server and share your feedback to help us improve.
Try the Forge MCP Server and share your feedback to help us improve.
For more information, see Forge MCP Server documentation.
Effective March 2, 2026, we are starting the phased enforcement of points-based quota rate limits for Jira and Confluence Cloud REST APIs. The rollout will begin with a small percentage of apps and gradually expand over several weeks, allowing us to closely monitor progress and minimize any disruption. API requests will start consuming points based on the work they perform, with app-level quotas applied consistently across two tiers:
Global Pool (Tier 1)
Per-Tenant Pool (Tier 2)
All Forge, Connect, and OAuth 2.0 (3LO) apps are in scope. API token-based traffic is not affected. The vast majority of apps are already operating well within these limits and will not be affected.
To learn whether points-based quota enforcement has started for your app, inspect your API response headers. Quota-related headers with a Beta- prefix (e.g., Beta-RateLimit-Policy: "global-app-quota") indicate enforcement has not yet begun for your app. When enforcement begins, these transition to their non-prefixed equivalents (e.g., RateLimit-Policy: "global-app-quota").
Jira REST APIs use multiple rate-limiting systems (quota, burst) that are transitioning to a unified structured headers(Beta-RateLimit, Beta-RateLimit-Policy)independently. The Beta- prefix on a header indicates that the system has not yet transitioned to production for your app. Use the policy name in the header (e.g., "global-app-quota" or "tenant-app-quota" for quota and for burst"jira-burst-based" ) to identify which system a header belongs to. Additional rate limit policy transitions to this unified header will be announced separately.
We plan to discontinue sending quota rate limit values via the X-RateLimit-* headers in the future. A timeline will be published separately.
For full details on how points are calculated, quota tiers, unified header format and values, and best practices for handling rate limits, please refer to:
Rate this page: