Atlassian developer changelog

To improve performance and address constantly evolving threats on the web, Atlassian is enabling AWS Cloudfront Content Delivery Network (CDN) and Web Application Firewall (WAF) for all Confluence and Jira Cloud Customers.

This rollout will occur over the next few months, country by country, progressively, with each country taking around 1-2 weeks to complete the migration.

This improvement may unfortunately impact some Jira and Confluence Cloud API integrations (like those written in Python, Node/JS, Java, libcurl, Axios, atlassian-connect-express etc) that attempt to make requests with URLs (including path and query string) longer than 8192 characters/bytes.

Where previously Jira and Confluence Cloud APIs handled paths longer than 8192 characters/bytes, AWS Cloudfront will actively reject such requests:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html

The maximum length of this URL is 8192 bytes.

If a request or a URL exceeds these maximums, CloudFront returns HTTP status code 413, Request Entity Too Large, to the viewer, and then terminates the TCP connection to the viewer.

Unfortunately, it is not possible to configure Cloudfront to allow longer URLs.

Atlassian products such as Loom, Trello, Opsgenie, Statuspage etc already reject 8192 characters/bytes urls.

For resolution instructions see more details below.

Atlassian Marketplace is transitioning to a scalable architecture by reengineering our monolithic data model and adopting a microservices-based approach to enhance reliability and scalability. With this, Marketplace partners will see some changes which will require adoption.

Key changes for Marketplace partners:

• Transition from V2 APIs:

  • Marketplace v3 REST APIs: We are making changes to the Marketplace APIs(https://developer.atlassian.com/platform/marketplace/rest/v2/intro/#), which will include deprecations—some with replacements (v3 APIs) and others without. The new v3 APIs will be available from Jun 30, 2025.

  • Deprecation of REST V1 APIs: All v1 APIs are deprecated and removed. To avoid disruptions, transition to v3 APIs.

• User experience enhancements: We are improving visual design of some of our experiences. These updates primarily focus on modernizing the tech stack and aligning with Atlassian Design Systems, replacing older designs.

For more information on implementation details and release dates, have a look at the Quick Reference Guide. Let us know your feedback as comments on the QRG.

Multi-instance licensing is now live!The Atlassian Marketplace has introduced a new level of flexibility in app billing and licensing. This enhancement allows Cloud Enterprise customers to be charged based on the number of unique users of the app across multiple instances, irrespective of the number of product instances.

Customer GA is targeted for May 2025. The capability to set multi-instance pricing for apps is available from today, Feb 20, 2025. We recommend planning and setting your new pricing by May 15, 2025.

• Multi-Instance Pricing: Partners must offer multi-instance pricing for paid cloud apps alongside single-instance pricing, with flexibility to set different prices.

• Existing Apps: Multi-instance pricing will be enabled by default, initially matching single-instance pricing.

• Default Pricing: The pricing console will default multi-instance pricing to 1x of single-instance pricing, but partners can adjust this multiplier or edit fields as needed.

• Customization: Partners can set multi-instance pricing as a price multiplier (≥1x of single-instance pricing) and edit pricing across different user tiers.

We have removed the following request body fields from the Update custom content REST API V2 endpoint:

• spaceId

• pageId

• blogPostId

• customContentId

These fields had no effect, so there is no impact on any clients who currently use them.

We’re happy to present the first Early Access Program (EAP) builds of Jira Software 10.5 and Jira Service Management 10.5. To find out what’s in scope of this EAP release, refer to Preparing for Jira 10.5.

You can download the current EAP from this page. If you’re using maven.atlassian.com, the version is 10.5.0-m0001.

This is a reminder about the changelog announcement regarding the deprecation of the Forge sandbox runtime on Aug 28, 2024.

The retirement of the sandbox runtime will take effect on Feb 28, 2025, upon which any apps using the sandbox runtime will stop working.

Please ensure you update your app before the Feb 28, 2025 using this guide.

To increase awareness of the impending deadline, apps using the sandbox runtime will be blocked from executing in all development environments beginning Feb 19, 2025.

If you have questions or concerns about this deprecation, please visit this community thread.

We have identified an issue within our system that resulted in the absence of customer feedback on churn events via the Feedback APIs between January to February 2025.

This issue has now been resolved, and consequently, 167,332 customer feedback records will be made available across all partners. These customer feedbacks were generated during the period from August 2020 to the present date. Effective Feb 20, 2025, partners will gain access to customer feedback regarding churn events from both historical and current feedback through reporting, as well as via the following APIs:

• Get feedback

• Export feedback

• Get aggregated feedback

All the Forge Bitbucket UI modules extension data now include a location property, which is available by calling the useProductContext hook. It provides the full URL of the host page where the module is displayed in. For more details, see the https://developer.atlassian.com/platform/forge/manifest-reference/modules/index-bitbucket/.

We have recently noticed an unusual increase in API usage. In order to maintain reliable services for both Atlassian customers and partners, we will begin enforcing more granular rate limits for Confluence and Jira APIs.

We will begin enforcing REST API (Quota and Burst based) rate limits for all free apps on or after August 18, 2025. We have added additional headers to provide further transparency. Please monitor header responses to see where you are at with regard to limits.

In some circumstances where apps are highly impacting the stability of our platform, we reserve the right to enforce the limits at an earlier date. We will notify your listed contact via email if you are impacted. Additionally, we are planning to bring clarity to rate limits across our platform infrastructure over the next year, including paid apps.

We recommend all customers and partners ensure they're not exceeding the rate limits so that they do not get impacted at a later date.

Learn more about the header responses and read relevant FAQs about rate limiting adjustments for Jira here and Confluence here.

We're excited to announce that we’re expanding the early access program (EAP) for App Editions to more partners. Our goal this time is to engage additional partners who have previously expressed interest and those who have recently shown enthusiasm for developing editions.

This approach will ensure readiness when we activate the customer General Availability (GA) switch, also known as Milestone 3, in Q2 of calendar year 2025. We have a quick but involved path from EAP to General Availability and are looking for our early adopters to work with us along the way.

Learn more about the EAP participation criteria and requirements here. If you’re interested in participating in the early access program Round 2, please complete the attached form by Mar 3, 2025.

The following Forge Bitbucket modules now support view.createHistory() via @forge/bridge:

• bitbucket:repoMainMenuPage

• bitbucket:repoSettingsMenuPage

• bitbucket:workspaceSettingsMenuPage

App developers can now utilize a path segment at the end of the page URL to maintain page history within their app. For more details, see https://developer.atlassian.com/platform/forge/apis-reference/ui-api-bridge/view/#createhistory.

Starting Feb 18, 2025 , we are introducing two updates:

1. New Billing System Field (newBillingSystem) in Marketplace reporting Licensing API

   • This field indicates whether a customer entitlement is on the new or old billing system.

   • Yes = Entitlement is on the new billing system

   • No = Entitlement is still on the old billing system

   • If case of free apps data this fields  is not available

   • This is particularly important for Marketplace partners participating in App Editions, as it helps identify which cloud customers are on the new vs. old billing system.

   • The field will be maintained when a customer transitions between billing systems.

2. Dual Licensing Discount Reason Code in Marketplace reporting Transactions API
   We have backfilled data for 62,000 transactions across various partner accounts to correctly display dual licensing discounts for records that were not displaying it earlier. These records were originally not displayed as DUAL_LICENSING but are now correctly labeled. To improve accuracy, we have enhanced our pipeline to map a specific internal reason code(which previously was a free text field) to dual licensing.

   Partners can access these discounts via the Transactions API and read the following fields:

   • Discount Type: Manual

   • Reason Code: DUAL_LICENSING

This endpoint will be deprecated in 6months per our developer communications guidelines (August 18, 2025). For any third-party scripts that rely on this endpoint, use the PUT labels/:id endpoint instead (documentation here).

We’ve added two new Bitbucket Forge product events: avi:bitbucket:resolved:pullrequest-comment and avi:bitbucket:reopened:pullrequest-comment. You can use these events to invoke your Forge app function when a pull request comment is resolved or reopened. For more details see https://developer.atlassian.com/platform/forge/events-reference/bitbucket/.

Starting 15 Feb 2025, we will no longer accept a request body for the GET Issue Limit Report API. Any API calls made with a request body will result in a 403 error. If you are using a request body with this API, you will need to modify requests to avoid errors.

The API can still be used without a request body. By default, issues approaching the limit will be returned at the 80% threshold of the limit.