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.
Rollout : progressive rollout by tenant. IN PROGRESS
We've updated the behavior of the Delete work type scheme API. Previously, you could delete work type schemes even when they were associated with projects. This is no longer allowed.
What's changing
Work type schemes that are associated with one or more projects can no longer be deleted
The Delete work type scheme API will return a validation error if you attempt to delete a scheme that is associated with projects
What you need to do
If you need to delete a work type scheme that is currently associated with projects, you must first reassign all projects to a different scheme:
Use the Get work type scheme API with the projects expand and id query parameter to get a list of projects associated with the scheme you want to delete
Use the Assign work type scheme to a project API to reassign all associated projects to another work type scheme
Once all projects have been reassigned, you can delete the unused scheme using the Delete work type scheme API
This change is not backward-compatible. Integrations that attempt to delete work type schemes associated with projects will now receive validation errors and must be updated to follow the migration steps above.
For more information, see:
Work type schemes in the Jira Platform REST API documentation
Community post: Project fields association improvements for additional context
Related: CHANGE-2527 (deprecation notice)
To reflect that Forge SQL & KVS Migrations are now suitable for use in production, the features have moved from Early Access to Preview status. Learn more at https://developer.atlassian.com/platform/app-migration/forge-storage/data-planes/
We're introducing new Beta rate-limit headers on Jira and Confluence REST APIs for points-based quota limits. These headers follow a unified, structured model aligned with standards on rate-limiting headers. They are informational only, they do not trigger enforcement or throttling. They are additive, and existing X-RateLimit-* headers continue to be returned.
Beta-RateLimit-Policy – policy definition
A static header that describes the rate-limit policy applied to the request.
Example: Beta-RateLimit-Policy: "global-app-quota";q=65000;w=3600
Beta-RateLimit – per‑response usage
A dynamic response header that provides usage signals for applicable rate-limit policies
Example: Beta-RateLimit: "global-app-quota";r=13000;t=600
When these two headers are returned without the Beta- prefix (RateLimit, RateLimit-Policy), points-based quota limits are actively enforced, and requests may be rate limited. For points-based quota enforcement, only RateLimit and RateLimit-Policy are used , the existing X-Beta-RateLimit-* and X-RateLimit-* headers will not be used. Standard HTTP headers such as Retry-After continue to apply where relevant.
For full details, including policy definitions and usage semantics, see the Jira Rate Limiting documentation here https://developer.atlassian.com/cloud/jira/platform/rate-limiting/ and Confluence Cloud Rate Limiting documentation here https://developer.atlassian.com/cloud/confluence/rate-limiting/
We have increased the workflow history storage period from 28 days to 60 days.
For more information, see the API documentation for List history for workflow and Read specific workflow version.
Additional Notes:
Workflow data from before Oct 30, 2025 remains unavailable as it predates this feature.
We have identified and fixed an issue where the purchaseDetails.discounts array (for discount type EXPERT) was not populated for some negative transaction line items.
Negative transaction lines usually represent credits for unused paid time.
“Unused paid time” refers to the credit a customer receives when they have already paid for a period of service but stop using it before the end of that period. Common example:
The customer upgrades to a higher user tier part‑way through the term. In these cases, the system issues a negative line (refund/credit) to return the unused portion of the original charge.
Sample Transaction: For a given upgrade from 400 → 500 user tier,
Transaction | Line # | Sales Type | Description | List amount | EXPERT discount | Net amount |
|---|---|---|---|---|---|---|
IN-test-10001 | 1 | Upgrade | Upgrade Example App 400 → 500 users | $500.00 | $100.00 | $400.00 |
IN-test-10001 | 2 | Refund | Credit for unused paid time on previous 400 tier | -$400.00 | -$80.00 | -$320.00 |
Line 2 is a negative transaction line (a credit) for unused paid time on the old 400‑user tier.
Previously:
Refund lines for unused paid time associated with Solution Partner Transactions, the discount amount was not populated in the EXPERT field on the transactions API.
As a result, partners could see a negative transaction amount (credit issued to the customer) but a zero or null expert discount amount on those same lines, making it difficult to reconcile discount treatment on credits.
This behavior has now been corrected. For all impacted transactions:
The EXPERT field is now correctly populated for unused paid time credit lines where an EXPERT discount was applied.
The EXPERT field will display the discount amount in Negative line (-80$ in the above example)
In total, this change updates ~17,000 transaction lines across Marketplace partners. Partners can check updated transactions using the last_updated field in the transactions API.
https://developer.atlassian.com/platform/marketplace/rest/v2/api-group-reporting/#api-vendors-vendorid-reporting-sales-transactions-get
We've increased the individual resource bundle size limit for Custom UI and UI Kit apps from 50 MB to 100 MB, allowing you to include larger assets and dependencies in each resource bundle.
Additionally, we've introduced cumulative limits that apply across all resources in your app to ensure optimal performance and resource management:
Total files: Maximum of 25,000 files across all resources in your app
Total bundle size: Maximum of 1 GB across all resources in your app
These cumulative limits apply regardless of how many individual resource bundles (up to 50) you use in your app.
For complete details on resource limits, see Resource limits.
We've introduced the useTheme hook for Forge UI Kit apps. This hook retrieves the current theme from the Atlassian app (Jira, Confluence, etc.) and reactively updates your Forge app when the theme changes.
The useTheme hook is now the preferred method for accessing theme information in UI Kit apps, replacing the previous approach of accessing theme.colorMode via useProductContext. Unlike useProductContext, the useTheme hook is reactive and automatically updates when the theme changes in the Atlassian app.
To use this hook, import useTheme from @forge/react and call it in your component. The hook returns a theme object containing the current theme configuration.
For implementation details and examples, see the `useTheme` hook documentation.
The view.onClose bridge method is now available in Confluence and Jira through Forge’s Early Access Program. To join the EAP, please complete this sign-up form.
view.onClose allows you to register a callback that runs when the extension point modal closes, such as the macro custom config modal. Upgrade to the latest version of @forge/cli to start building with the view.onClose() method.
For more information, see the updated documentation for the view bridge methods.
The fullscreen viewport size for macro custom config modal, UI Kit Modal and bridge modal is now available in Confluence and Jira, through Forge’s Early Access Program. To join the EAP, please complete this sign-up form.
Upgrade to the latest version of @forge/cli to start building with the fullscreen viewport.
For more information, see the updated documentation for the UI Kit Modal, bridge modal and macro.
You can now set custom colors for UI Kit Visualisation charts. You can either set a color theme or assign colors to attributes. This can be done by passing the prop colorPalette into your chart.
For an example of how to implement this, please see the Forge UI Kit example app at https://bitbucket.org/atlassian/ui-kit-charts-example/src/master/.
For more information, see documentation.
New experimental APIs for managing customers and organizations are now available. This release includes:
Simple APIs — Create, read, update, and delete individual entities
Bulk APIs — Manage multiple entities in a single request (our first async APIs for CSM)
Task APIs — Track the status of long-running async operations
The new experimental APIs are as the following:
These APIs introduce a new model for configuring customer and organization profiles. This is also the first release of asynchronous bulk APIs for CSM customer context.
For bulk operations, include the Idempotency-Key header in your requests. See the Bulk APIs guide for implementation details.
We’re simplifying how fields are associated and configured in Jira by introducing field schemes, a new model that will replace field configurations and field configuration schemes. This change also affects how field contexts will be used for visibility.
Field schemes will become the source of truth of what work types a field can appear on for Spaces.
Field contexts define the default values for fields and the options that are available for users to select. Given contexts will no longer be used to restrict where fields are available, every field will have a global context which is always present and cannot be deleted.
Screens, Screen schemes and Work item layouts determine what users see when they are creating or viewing a work item in the full page view.
This will involve the following changes:
Component | Update | Date |
|---|---|---|
New field associations | Open Beta (sign up here) | February 2026 |
GA | April 2026 | |
removed (see More details for complete list of APIs) | July 2026 | |
All unused fields from schemes | removed (to improve Jira’s performance) | July 2026 |
For more context, please review the announcement blog post and related RFCs.
To determine or manage a fields availability we recommend using APIs that support both field configurations and the future field schemes, namely:
Get fields for projects NEW (see RFC-104)
Field schemes NEW (see RFC-105)
The following API changes will be implemented on Feb 2026 for beta customers, April 2026 for GA:
Delete custom field context: will no longer support removing global contexts.
Add issue types to context: will no longer support restricting the global context to certain issue types.
Assign custom field context to projects: will no longer support restricting the global context to certain projects.
To assign a context with specific projects or issue types we recommend creating a new context, rather than modifying the global context.
Create project: changes to template format (see RFC-121).
All Field configuration APIs will be removed on July 2026:
We are extending the deprecation period of the Convert content body v1 REST API in Confluence Cloud to Aug 5, 2026 .
This API was originally scheduled for removal on Feb 1, 2026. We also advised that affected developers use the Asynchronously convert content body endpoint instead. However, we’ve discovered some issues that may prevent them from doing so (please refer to CONFCLOUD-82501 for details and updates on this).
We expect to have all related issues addressed before this new deprecation period ends.
We've added a new field product_id to the CSV file returned by the Get latest product catalog snapshot v3 API. All the existing fields are untouched and they remain as-is. For more details, please refer to the documentation of the aforementioned API.
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.
Rate this page: