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.
You can now deploy Forge app builds directly via the developer console.
Selecting Deploy build from the actions menu next for the build you want to deploy.
Select the environment to which you’re deploying the build to.
Note, app build deployment permissions adhere to the existing permission structure for app contributors.
We have fixed an issue in how compute usage was calculated for async events and scheduled triggers in Forge apps.
This change was rolled out progressively between Dec 17, 2025 and Dec 19, 2025. As a result, affected apps may now report higher compute usage than before. This reflects more accurate tracking of the resources consumed; there is no change to the actual behavior or performance of your apps.
If you have alerts, monitoring, or internal reports based on Forge usage metrics, you may want to review them to account for this correction.
Logs automatically generated by the Forge platform during remote invocations (not logs generated by the app itself) are removed. The following platform-generated log statements are impacted:
Making remote request: When remote invocation is triggered
Successful remote request: When remote invocation was successful
Failed remote request: When remote invocation fails
These logs will no longer be visible on the logs page in the developer console or in the logs CLI command. As a result, they are excluded from usage calculations and billing.
Developers utilising Forge remote will notice a reduction in their logs usage starting today.
To maintain visibility into remote invocations, we will be introducing success and failure information via metrics in the near future.
The cleanHistory field will be deprecated on June 30, 2026. As part of this deprecation, we’re changing the cleanHistory field in Content Redaction API requests from required to optional.
Existing implementations that include the cleanHistory field will continue to function during the deprecation period. However, we recommend that you start implementing the following changes for any apps impacted by this change:
Update your API client to treat cleanHistory as an optional field.
Use the versionNumber field to specify the historical version you want to redact.
Remove the cleanHistory parameter from your redaction requests.
Summary
Migration window: 5 Jan 2026 – 29 Jan 2026
What’s happening: We’re moving Data Center promotion codes from the legacy billing system to our new billing system.
During this time:
All active promotion codes continue to work as normal.
Customers can continue to redeem and use all active promotion codes as normal.
Partners can continue to view active promotion codes in:
Partner Portal UI, and
Promotions API.
Only redeemed inactive promotion codes (expired codes that have already been used) will not be visible in the
Partner Portal UI or
the Promotions API https://developer.atlassian.com/platform/marketplace/rest/v1/api-group-promotions/#api-marketplace-catalog-partners-partnerid-promotions-paged-get during the migration window.
Redeemed inactive promotion codes are promotion codes that have already been used and have since expired.
After the Migration Window:
Redeemed Inactive Promotion codes will be backfilled and provided on Partner portal UI and API.
Effective 29 January 2026, Bundled promotion codes will no longer be supported (i.e., codes that discount two or more partner-specific apps at once).
There is no migration of Data Center licenses in this window. Any updates about DC license migration will be shared separately.
We are migrating marketplace promotion codes from the legacy billing system to our new billing system. This migration aligns Data Center promotion processing more closely with how we handle cloud promotion codes today, and helps ensure data consistency and integrity across systems.
During the migration window, only redeemed inactive promotion codes will:
Not appear in the Partner Portal UI
Not be returned by the Promotions API:GET /marketplace/catalog/partners/{partnerId}/promotions/paged
(see docs: https://developer.atlassian.com/platform/marketplace/rest/v1/api-group-promotions/#api-marketplace-catalog-partners-partnerid-promotions-paged-get))
We require a short, controlled window to safely migrate promotion code data, ensuring data integrity and consistency across systems.
Promotion codes will be processed by the new billing system similar to cloud promotion codes going forward.
Area | Old Billing System | New Billing System |
|---|---|---|
Data Center Promotion Code creation Flow | Partners can create a single promotion code that can be redeemed across one or multiple apps (bundled promotions - These are promotions that applied in the old billing system on bundled purchases, i.e., only when two specific partner apps were in the cart) | Each promotion code is scoped to one specific app only. Effective Jan 5, 2026, we will end ability to create new bundled promotions/ promotion codes. Effective Jan 29, 2026, Data Center bundled promotion codes will no longer be supported. This simplifies the process for both partners and customers, making promotion code usage clear and consistent across cloud and data center. |
Data Center Promotion Code status | Partners will be able to view
| Partners will be able to view
|
Reporting & Reconciliation (no Changes) | Use | No change, continue to use |
If you rely on historical redeemed inactive promotion codes, Export or record any needed data (bundled or standalone) via:
Partner Portal UI, or
If you need redeemed inactive promotion data or Bundled promotion code during the migration window(5 Jan - 29 Jan 2026), please raise an ECO-HELP ticket and we can retrieve it for you.
Redeemed inactive promotion codes will be backfilled and visible again in both:
the Partner Portal UI, and
the Promotions API byJan 29, 2026 .
We’re releasing an experimental REST API endpoint that allows you to switch workflow schemes for projects with improved performance and reliability.
POST /rest/api/3/workflowscheme/project/switch
The API accepts mapping instructions to handle updates for issues and performs asynchronous operations that leverages temporary schemes and workflows to co-ordinate updates efficiently and safely.
Enhanced performance and reliability
Support for projects with existing issues
Asynchronous processing with progress tracking
Comprehensive issue status migration handling
Requires Administer Jira global permission.
See the Switch workflow scheme for project API documentation.
We’ve added two new REST API operations that let you access historical version data for workflows in Jira Cloud. These endpoints make it easier to audit and review previous workflow versions.
You can now:
List all stored versions for a specific workflow using the List history for workflow operation.
POST /rest/api/3/workflow/history/list
Retrieve a specific workflow version from history using the Read specific workflow version operation.
POST /rest/api/3/workflow/history
Permissions required:
To access all workflows: Administer Jira global permission.
To access project-scoped workflows: Either Administer projects or View (read-only) workflow project permission.
For more information, see the API documentation for List history for workflow and Read specific workflow version.
Notes:
We only store workflow data dating back 28 days
Workflow data from before Oct 30, 2025 is not available.
You can now use UI modifications with Jira Service Management (JSM) request create portal view. This is an extension of the existing jira:uiModifications module, allowing you to change the look and behaviour of JSM request create portal view. The module is designed to be used in conjunction with the UI modifications (apps) REST API.
For more information, see the JSM UI modifications module documentation.
Support for response streaming is now available in Forge LLMs. The new stream function in the @forge/llm SDK allows apps to process outputs as they are generated rather than waiting for the complete response.
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.
As part of the Forge platform pricing effective from Jan 1, 2026, we have introduced usage alerts. Developers will automatically receive notifications when the usage of any billable capability in the Forge app reaches key thresholds— at 50%, 75%, 90%, and 100% of free monthly usage allowance.
We’re introducing two new APIs to assign and remove organization-level roles. These APIs let organization admins assign or remove roles that have organization-wide privileges. Currently, this only applies to the organization admin role.
This API is available to all customers.
The following UI Kit components are now generally available:
Comment, which displays discussions and user feedback.
Pressable, which is a primitive for building custom buttons.
CommentEditor, provides a contained comment editor UI with a simple toolbar.
ChromelessEditor, provides a simple text editor that does not have a toolbar.
For more information, see the component documentation.
To access these components, you will need to update your app to the latest version of @forge/react. In the terminal of your project directory, run:
npm install --save @forge/react@latest
We’re announcing the deprecation of the V2 Categories APIs on Atlassian Marketplace.
What’s changing
The V2 Get categories , V2 Get category are now deprecated.
A six-month deprecation window begins immediately, and these APIs will be removed after June 30, 2026 .
What you need to do
Partners and developers should migrate to the new APIs to ensure continued functionality and support. Refer to the updated documentation for Get Product Tags , Get product tag APIs to plan your transition.
For more details on the migration process from V2 to V3 APIs, please refer to this Quick Reference Guide (QRG): https://atlassianpartners.atlassian.net/wiki/spaces/resources/pages/735608891/Marketplace+Platform+Changes+GA+and+Partner+Implications+-+Quick+Reference+Guide .
For the final API endpoints and response structures, please refer to the latest documentation present on DAC. We appreciate your cooperation and look forward to ushering in a more streamlined and efficient Atlassian Marketplace experience. Thank you for your continued support.
We’re announcing the deprecation of the V2 Licenses APIs on Atlassian Marketplace.
What’s changing
The V2 Get License Type , V2 Get License Types are now deprecated.
A six-month deprecation window begins immediately, and these APIs will be removed after June 30, 2026 .
What you need to do
This is a static list. You can get the valid license types from the response body of - V3 Get app software version by build number
Partners and developers should migrate to the V3 APIs to ensure continued functionality and support.
For more details on the migration process from V2 to V3 APIs, please refer to this Quick Reference Guide (QRG): https://atlassianpartners.atlassian.net/wiki/spaces/resources/pages/735608891/Marketplace+Platform+Changes+GA+and+Partner+Implications+-+Quick+Reference+Guide .
For the final API endpoints and response structures, please refer to the latest documentation present on DAC.
We appreciate your cooperation and look forward to ushering in a more streamlined and efficient Atlassian Marketplace experience. Thank you for your continued support.
New Formula custom field in Jira
We’ve started rolling out a new NumberFormulaField custom field type in team-managed spaces.
This rollout will be completed by Dec 19, 2025, excluding bundled release track customers. Support for company-managed spaces, as well as additional formula field types (TextFormulaField and DateFormulaField), will follow in the calendar year 2026.
These custom field types lets teams calculate field values based on data from Jira work items, which enables more dynamic and automated data handling within Jira.
No new APIs are required for configuring these fields; configuration is managed within the Jira application. Calculated values will be accessible via the existing API for reading field and issue data. See the Jira Cloud platform REST API documentation to know more about accessing calculated values via the API.
Rate this page: