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.
Forge Cache EAP has closed. The service will not progress to GA, as we are shifting our investments to better address developer use-cases.
We will not be accepting any new sign-ups to the EAP from Aug 29, 2025
The EAP environment will be decommissioned and all cache data deleted after Sep 30, 2025
We are still committed to solving the underlying use-cases that led us to develop Forge Cache, taking what we’ve learned from the EAP and applying it to solutions that will offer better outcomes for developers.
Thank you to all of the EAP participants for helping us test Forge Cache and enabling us to build a better platform.
Over the past several months, we’ve been closely evaluating Forge Cache based on feedback from our developer community and partners, as well as broader strategic shifts within Atlassian. Here are the key factors that have shaped our decision:
Performance limitations: Forge Cache’s current performance (P90 of 20-30ms) does not meet industry standards for low-latency caching. This has been a consistent pain point for developers building latency-sensitive applications.
Missing developer needs: Many use cases require data persistence, dynamic or long TTLs, and advanced features like job queuing—capabilities that go beyond what a simple cache can provide.
Multi-cloud strategy: Atlassian is investing in a multi-cloud strategy, with deployment options to isolated cloud, government cloud and Google Cloud Platform. Achieving the low latency expected from a cache is only possible once Forge Functions and Forge Containers are supported within the same cloud platform, which is not feasible in the near term.
Given these factors, we have decided not to progress Forge Cache to General Availability (GA). Instead, we are shifting our investments to better address the broader developer needs:
All timelines are indicative and subject to change.
Q2 FY26:
Forge KVS Enhancements: We will introduce new capabilities such as Conditional SET with TTL. Transactions for KVS has already shipped, enabling atomic operations.
Q3–Q4 FY26:
Performance Improvements: We are targeting Forge KVS performance to reach a P90 of 40–50ms, narrowing the gap with Forge Cache.
FY27:
FIFO Queues: Launching a new FIFO Queues service to help developers queue jobs and break up large computations—addressing a top-requested feature.
Container-Based Compute Cache: We plan to invest in a new container-based compute cache, designed to deliver even faster performance and support advanced caching scenarios.
Forge Cache EAP will close: We will not be accepting any new sign-ups to the EAP from Aug 29, 2025. The EAP environment will be decommissioned and all cache data deleted after Sep 30, 2025.
Forge Cache will not move to GA. We recommend to evaluate use of Forge KVS for your use case.
Feature Parity: We are working to ensure that Forge KVS and the new services will cover the majority of use cases previously addressed by Forge Cache, with additional benefits like data persistence and transactional support.
We understand this decision may be disappointing to some users, however, we believe it is the right strategic path for Forge. We are still committed to solving the underlying use-cases that led us to develop Forge Cache, taking what we’ve learned and applying it to solutions that will offer better outcomes for developers.
As we progress with above roadmapped improvements, we will provide updates on developer community, Forge changelog and on our public roadmap.
To support Jira performance at scale, we are introducing a limit on how many work types and how many fields can be associated to a company-managed project in Jira cloud:
The admin user interface and related APIs will restrict the association of more than 150 work types to a single work type scheme.
Similarly, they will also limit the association of more than 700 fields within the single field configuration scheme.
The limit will be effective starting Feb 9, 2026.
Exemption which will be allowed to go over these limits. Examples include:
Installing a new app
Enabling a new product
Upgrading (or downgrading) a license tier
Creating a new project
Migrations
Jira Admins will have access to streamlining tools designed to eliminate unused fields and work types. This initiative aims to ensure that the field configuration scheme and work type scheme remain within the established limits.
Support documents
This is building on top of what we announced in https://community.atlassian.com/forums/Jira-articles/Announcement-Changes-to-field-and-work-type-configuration-in/ba-p/3023478
Fields https://support.atlassian.com/jira-cloud-administration/docs/optimize-fields-in-your-project/
Work types https://support.atlassian.com/jira-cloud-administration/docs/optimize-work-types/
The following APIs will be impacted:
Add work type to a work type scheme: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-type-schemes/#api-rest-api-3-issuetypescheme-issuetypeschemeid-issuetype-put will return HTTP 400 if the scheme is over a limit
Create issue type scheme: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-type-schemes/#api-rest-api-3-issuetypescheme-post will return HTTP 400 if the issue type count is over a limit
Assign work types to field configurations: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-field-configurations/#api-rest-api-3-fieldconfigurationscheme-id-mapping-put will return HTTP 400 if the scheme is over a limit
Team-managed projects already have their own limits:
There is a limit on how many work types can be in a team-managed project: https://support.atlassian.com/jira-software-cloud/docs/set-up-issue-types-in-team-managed-projects/ this limit remains unchanged
There is a limit on how many project scoped fields can be created in a team-managed project: https://support.atlassian.com/jira-software-cloud/docs/customize-an-issues-fields-in-team-managed-projects/. The amount of global scoped fields is unlimited. This will change so that team-managed projects will now observe the same limit of fields as company-managed projects.
We are announcing the deprecation of the following Compass GraphQL API fields:
createComponentFromTemplate
createWebhook
userDefinedParameters
updateUserDefinedParameters
These APIs will be removed on December 1, 2025.
Why is this deprecation necessary? The Compass Templates feature is being removed. See the community post for more details.
In an effort to continue improving performance and scalability of Bitbucket Cloud, we will be deprecating cross-workspace APIs.
On Feb 27, 2026 we will be removing the following endpoints:
/2.0/repositories
/2.0/user/permissions/repositories
/2.0/snippets
/2.0/user/permissions/workspaces
/2.0/workspaces
Bitbucket will be introducing replacements for each of these endpoints with single workspace-scoped versions. We will create another announcement as soon as they become available.
If you are using any of the endpoints listed above in your custom integration or as an extension app that you have built on top of Bitbucket, your integration/app will be impacted and you will need to switch to the new APIs prior to deprecation date.
Atlassian is introducing burst API rate limiting for Jira Cloud to enhance reliability and performance. This industry standard approach helps prevent service disruptions by controlling excessive API requests from apps and scripts using API tokens, ensuring a smoother experience for all users.
How burst rate limiting works:
Per-tenant and per-API limits. All programmatic requests (from apps or API tokens) for a tenant share the same API bucket, regardless of the number of API token tokens or installed apps.
Short bursts allowed. The system uses a token bucket algorithm, which allows short bursts of traffic while maintaining a sustainable average rate over time maintained by the number of tokens to refill.
Consistent experience. Limits are applied consistently across all Cloud plans and are not affected by the number of seats or installed apps. Though, limits can be requested to be extended for valid uses cases when traffic is not heavily concentrated in short time periods.
Transparent enforcement. If your requests exceed the allowed rate, you will receive an HTTP 429 ("Too Many Requests") response.
Here are the benefits for you:
More predictable and reliable API performance.
Fewer disruptions to critical front end operations.
Improved infrastructure efficiency and scalability.
What to do if you are rate limited:
Review your integration to ensure it is not sending excessive bursts of requests.
Implement retry logic with exponential backoff and respect the Retry-After header in 429 responses.
Monitor your API usage and adjust as needed.
While version 3 of the Marketplace privacy and security APIs is still under development, we’re releasing the documentation for these Marketplace app software APIs early to help you prepare for the upcoming changes. This release includes a preview of the API documentation schema and examples of API requests and responses.
To ensure smooth transition with the upcoming changes, we recommend to review the API documentation to understand and prepare for the upcoming changes.
Here are some helpful suggestions for you to consider:
Transition planning: Based on this documentation, it may be helpful to assess the bandwidth required for these changes and incorporate them into your roadmaps. Reviewing this documentation could provide a clearer understanding of the new APIs and help you accurately estimate the efforts involved in the transition.
Project planning: Consider preparing your execution plans and project plans so that you’re ready to hit the ground running once the APIs become available.
Staying informed: Keeping an eye out for upcoming communications from the Marketplace team can help you stay updated on timelines. Look out for updates via changelogs, enhancements to the quick reference guide on the Partner Portal, DAC, and other channels.
Since our previous announcement about the analytics tool policy for Forge apps, we have received feedback from the developer community. Based on this feedback and customer requirements, we will explore a long-term solution that meets the needs of our mutual customers. As such, we are temporarily updating the analytics tool policy for Forge apps.
Effective 28 August 2025, we will allow tools with session recording features, script aggregators, and developer observability tools. While we explore long-term solutions, we will provide at least four weeks' notice before implementing any further changes to the policy.
As an app developer, please remember the Shared responsibility model and continue to prioritize customer data security.
As mentioned in our previous changelog regarding the vendor details APIs served by Atlassian Marketplace, we have now removed these APIs. Consequently, partners will no longer be able to access them.
Guide to replacing vendor APIs with developer space APIs
Vendor API | Replacement API |
|---|---|
Add vendor contact | |
Delete vendor contact | |
Update vendor contact | |
Get vendor contacts | |
Get vendor contact | |
Get vendor | |
Update vendor | No replacement |
Get all vendors | No replacement |
Create vendor | No replacement |
Get payment details | No replacement |
Create/update payment details | No replacement |
License import API | No replacement |
For more information, see the Marketplace Partners: Changes to Vendor Detail APIs - Quick Reference Guide
The access pattern has been changed to developerId, which is a unique identifier for a developer space.
Here is the API which will give the mapping of vendorId to developerId
Below is the mapping of vendor attributes to developer space attributes
Vendor attribute | Developer space attribute & API to access the attribute |
|---|---|
Vendor Id | Developer ID (API) |
Name | Name (API) |
Vendor’s listing attributes (e.g. email, phone, address, etc) | Developer space’s listing attributes (API) |
Vendor contact’s permissions | Developer space member’s roles (API) |
Vendor contact’s roles | Developer space member’s categories (API) |
We've simplified user access management with predefined roles. Admins can now easily assign granular access levels to team members using these curated roles.
These new Developer Space member roles replace the previous Vendor Contact permissions. Details about these roles and their corresponding permissions are available in the previously published RFC.
On Jul 28, 2025, we announced the addition of number field formatting through the Atlassian GraphQL Gateway (AGG) for company-managed projects in Jira.
We’ll start progressively rolling out this change to each tenant today (Aug 27, 2025). We expect to finish this rollout on Sep 11, 2025.
We are announcing the deprecation of the following Connect Javascript API methods:
getContentProperty
setContentProperty
syncPropertyFromServer
Deprecation announcement: August 26, 2025
Removal date: February 26, 2026
These methods use the deprecated V1 REST APIs.
On and after the removal date, all requests to the listed methods will result in a 404 Not Found response.
We recommend migrating to the V2 for these methods before the removal date.
getContentPropertyV2
syncPropertyFromServerV2
postPropertyToServerV2
updatePropertyToServerV2
Forge CLI now supports listing recent deployments using a new command, forge deploy list.
This command, by default, will show a table of the app’s recent deployments sorted by deployment date. It includes relevant details, including the environment and version, as well as the new “build tag” if the deployment was made using the forge build command. It also supports JSON output using the --json option, similar to other list commands in the Forge CLI.
Run npm install -g @forge/cli@latest on the command line to install the latest version of @forge/cli and receive these changes.
The ability to build a custom Teamwork Graph connector using Forge is now in EAP. Connectors allow you to ingest your app data into the Graph, associate it with Atlassian objects (for example, work items), and make the data available to customers in platform experiences like Chat, Search and Agents.
If you’re interested in joining the EAP, we recommend first checking the supported object types to see if we support your use case. Support for custom object types will come in a future release (2026).
To participate, please sign up for the EAP here.
We're deprecating the createComponentScorecardJiraIssue, updateComponentScorecardJiraIssue, and activeIssues fields in Compass. These fields will be replaced by createComponentScorecardWorkItem, updateComponentScorecardWorkItem, and activeWorkItems.
This change will take effect on October 1, 2025.
Why is this deprecation necessary? The new fields provide enhanced functionality and better integration with Compass.
What is changing? Developers should transition to using the new fields: createComponentScorecardWorkItem, updateComponentScorecardWorkItem, and activeWorkItems.
Dates and rollout: The deprecation will be effective from October 1, 2025.
For more information, see the Compass API documentation https://developer.atlassian.com/cloud/compass/graphql/#overview.
The Forge CLI is now available via a development container for both VS Code and IntelliJ. It provides a consistent and isolated environment that is pre-configured with the necessary dependencies to build Forge apps.
To get started, follow this guide to install the necessary tooling and set up your environment.
As part of the Crowd 7.0 release, we've introduced a new method for creating service accounts. Service accounts are specialized, non-user accounts created for secure and efficient management of automated processes and external integrations.
You can now create service accounts in Crowd using REST APIs with OAuth 2.0 authentication.
We're also working to provide a new user interface to make it even easier to create service accounts across products.
Please let us know if you have any feedback or questions.
Rate this page: