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 are changing the way we measure rate limits across Jira and Confluence Cloud for all free and paid apps. A phased enforcement of the new rate limits will begin on February 2nd, 2026.
When the phased enforcement begins, API requests then start consuming points based on the work they perform, such as the data (objects) returned or operations triggered. Each request starts at a base point of 1 point, with additional points for each object involved.
We’re also introducing two types of app-level quotas (tiers) that apply consistently across the Atlassian platform for all apps.
It’s important to note that the vast majority of free and paid apps do not require any changes and are already operating within these limits. We’ve also reviewed usage and upgraded eligible apps to a higher tier where appropriate.
If your app requires additional capacity in the future, rest assured we will provide clear pathways to request for this. For more information, please refer to the following documentation:
Here’s how the points-based limiting works.
Points-based measurement | API requests consume points based on the work they perform, such as the data (objects) returned or operations triggered. Each request starts at a base point of 1 point, with additional points for each object involved. |
|---|---|
Two-tier quota system | Apps start in Tier 1 - Global Pool, with a shared hourly quota across all tenants. Apps with consistently high or concentrated usage may qualify for Tier-2 Per‑Tenant Pool, which provides dedicated hourly quotas per tenant. |
Points-based costs | Different objects have different point values:
|
Hourly quotas by edition | Quotas reset at the top of each UTC hour. Per-tenant pool quotas vary by customer edition and number of users. |
Here are the benefits for you:
Fairer limits, heavy operations use more quota than simple ones.
This provides more predictable API usage planning and scaling.
This gives you better visibility through detailed rate limit headers.
The vast majority of free and paid apps already operating well within the new limits.
Some updates you need to know:
Updates to the RateLimit-Reason header with new reasons:
jira-quota-global-based, which refers to the Global pool limits being breached in Jira
jira-quota-tenant-based, which refers to the Per Tenant pool limits being breached in Jira
confluence-quota-global-based, which refers to the Global pool limits being breached in Confluence
confluence-quota-tenant-based, which refers to the Per Tenant pool limits being breached in Confluence
Updates to the developer documentation regarding rate limit quotas for different tiers in both Jira and Confluence
Planned updates to the developer console to show which tier your app belongs to ahead of the enforcement
Portfolio Insights will now include an expanded app assessment with information about Marketplace apps for migrating customers. This functionality is similar to app assessments from the migration assistants, and re-uses data provided by Marketplace partners through both Atlassian Marketplace and the App migration platform.
The goal of this functionality is to provide more information about apps earlier in the migration journey so that users have enough time to prepare and work together with Marketplace partners. Atlassian migration teams will also have access to this information so they can better support our users in their migration.
The expanded app assessment is based on existing resources provided by Marketplace partners on the Atlassian Marketplace or through the App migration platform.
It includes the following information for every app:
Cloud availability: Whether a cloud version of the app is available.
Migration path: What migration pathway is available, re-used from the App migration platform, with options, such as Automated, Manual, or Install only and links to migration documentation provided by Marketplace partners.
Overview information: General information about the app, re-used from the Atlassian Marketplace.
After assessing their instances, users can now view all of their user-installed apps, with additional information on each app’s cloud versions, migration pathways, and overview information.
The entries for ScriptRunner, Zephyr, and Xray also include the number of important entities, how they compare against migration guardrails, and migration recommendation.
Example from Xray:
Users will see the number of custom-built apps they have on their instance, with a way to review them in Data Center.
We recently introduced new Directory, Users, and Groups REST APIs, available for all customers to manage their users and groups. These APIs supersede several existing REST APIs, which we’re removing in June 2026.
The following v1 APIs will stop working after June 30, 2026:
Users
Search for users in an organization: POST/v1/orgs/{orgId}/users/search
Suspend user access: POST/v1/orgs/{orgId}/directory/users/{accountId}/suspend-access
Restore user access: POST/v1/orgs/{orgId}/directory/users/{accountId}/restore-access
Remove user access: DEL/v1/orgs/{orgId}/directory/users/{accountId}
Groups
Search for groups within an organization: POST/v1/orgs/{orgId}/groups/search
Create group: POST/v1/orgs/{orgId}/directory/groups
Delete group: DEL/v1/orgs/{orgId}/directory/groups/{groupId}
Assign roles to a group: POST/v1/orgs/{orgId}/directory/groups/{groupId}/roles/assign
Revoke roles from a group: POST/v1/orgs/{orgId}/directory/groups/{groupId}/roles/revoke
Add user to group: POST/v1/orgs/{orgId}/directory/groups/{groupId}/memberships
Remove user from group: DEL/v1/orgs/{orgId}/directory/groups/{groupId}/memberships/{accountId}
These v1 APIs are only available to customers with the centralized user management experience.
We recently released new organization REST APIs that are available to all customers to manage their users and groups. Read the announcement
We recommend you update your workflows to the new APIs as soon as possible to avoid any disruption.
Currently, the new workflow editor is the default editing experience in Jira and is being used by the majority of customers.
Starting 26th June 2026, we will begin removing the old workflow editor for customers, which means workflows will only be editable in the new workflow editor. We ask you to please help your customers in this transition by ensuring that any workflow-related apps will work effectively with the new workflow editor.
If you encounter any issues with how your apps behave in the new workflow editor, please raise a support ticket.
Some features to be aware of to improve app experiences in the new editor:
Dynamic configuration descriptions (Forge/Connect)
Make sure to provide a unique description for configured rules.
Additional context (Forge/Connect)
Determine whether the rule is loaded in the new or old workflow editor.
Default workflow editor for user (API)
Determine whether a user has a preference set for the new or old editor.
Deep linking to statuses and transitions
Link to the new workflow editor and provide an ID with either the selectedStatus or selectedTransition query params to pre-select a status or transition.
We updated the Get users in an organization API to expand the response, add more fields, and support more filters.
Expanded response
Previously, this API only returned users in your directories. Now, this API will also return your organization’s managed accounts, even if they’re not in a directory.
New fields
Additionally, these new fields will be returned for managed accounts:
managementSource — Whether this account was manually invited to a directory or synced from an identity provider
mfaEnabled — Whether or not two-step verification is enabled on this account
forDeletion — Whether or not this account is scheduled for deletion
jobTitle — Job title of the user
department — Department the user belongs to
organization — Organization the user belongs to
location — Location of the user
timeZone — Time zone the user is in
Many of these fields are also returned in the existing Identity API to Retrieve a user profile and synchronization data (all data).
New filters
The following request filters are now available for Get users in an organization API:
emailVerified — Filter accounts by whether or not their email has been verified
mfaEnabled — Filter accounts by whether or not two-step verification is enabled on the account
forDeletion — Filter accounts by whether or not they’re scheduled for deletion
emailDomains — Filter by email domain of the account (only possible with verified domains)
You can still use Get managed accounts in an organization API if you need the following fields that aren’t available with Get users in an organization API:
access_billable — Whether or not this account is billable for Atlassian Guard
last_active — When this account was last active
product_access — Which apps this account has access to
We updated the Get count of users in an organization API to support more filters.
The following request filters are now available for Get count of users in an organization API:
emailVerified — Filter accounts by whether or not their email has been verified
mfaEnabled — Filter accounts by whether or not two-step verification is enabled on the account
forDeletion — Filter accounts by whether or not they’re scheduled for deletion
emailDomains — Filter by email domain of the account (only possible with verified domains)
We updated the Get user stats API to expand the response. The response will now include claimStatus, which provides the total number of managed accounts claimed by your organization.
1
2
3
4
5
6
"claimStatus": [
{
"status": "managed",
"count": 32
}
]We are deprecating v2 App pricing APIs (Get pricing API & Submit pricing API) and providing replacement for those APIs via APIs powered by Atlassian Commerce platform.
This document will guide you on how to use the new Commerce APIs.
Currently, Marketplace Partners can set app pricing in two ways: either through the Marketplace Partner Console UI or by using the Marketplace v2 APIs. However, the Marketplace API only supports managing pricing for the Standard edition of apps.
In the future, partners will continue to have two options for setting pricing: the Marketplace UI or a new API provided via the Commerce. The Commerce API will offer enhanced capabilities, allowing partners to manage pricing for different editions, multi-instance apps, and handle Atlassian Government Cloud (AGC) & Isolated Cloud-related packaging and pricing requirements.
We’re deprecating below Marketplace v2 pricing APIs:
GET /addons/{addonKey}/pricing/{cloudOrServer}/{liveOrPending}
PUT /addons/{addonKey}/pricing/{cloudOrServer}/{liveOrPending}
Deprecation schedule
Deprecation announcement date: Dec 10, 2025
End of support date: Jun 30, 2026
Removal or behavior change date: Jun 30, 2026
After the removal date
Calls to the v2 pricing APIs will return error with status 410 (Gone)
What you need to do
Stop using the v2 Pricing APIs.
Use the Commerce Pricing APIs described in this guide to:
Update App Pricing
Fetch App Pricing across editions and offerings.
Here is the list of app pricing APIs with consolidated decision
Pricing API | Decision |
|---|---|
Get App pricing https://developer.atlassian.com/platform/marketplace/rest/v2/api-group-apps/#api-addons-addonkey-pricing-cloudorserver-liveorpending-get | REPLACEMENT |
Submit app pricing https://developer.atlassian.com/platform/marketplace/rest/v2/api-group-apps/#api-addons-addonkey-pricing-cloudorserver-liveorpending-put | REPLACEMENT |
This is for Marketplace Partner who want to use APIs to Update or Fetch Pricing of their apps
https://developer.atlassian.com/platform/marketplace/marketplace-app-pricing-api/
Forge usage invoices for December 2025 will be generated on January 1st, 2026, and all usage during December is fully discounted. This allows you to experience the complete billing flow, including adding a payment method, reviewing usage, and receiving an invoice, before Forge pricing changes take effect on 1 January 2026. See the Atlassian blog for more details about the upcoming pricing changes.
This release includes:
Developer Spaces
A Developer Space is your team’s shared space for building, managing, and billing Forge apps. It brings together your apps, team members, and billing access in one place, making it easier to collaborate and organize your portfolio. Learn more in Introduction to Developer Spaces.
Create Developer Spaces from the Forge CLI
By using the CLI version 12.9.0 or above, you can create Developer Spaces and assign apps via the Forge CLI during forge create or forge register workflows.
Run npm install -g @forge/cli@latest on the command line to install the latest version of @forge/cli.
Billing experience
You can now experience the complete billing journey for a Developer Space—from adding a payment method to receiving a fully discounted invoice for December 2025 usage. This helps you familiarize yourself with the process before pricing takes effect from January 1st, 2026 onwards. Learn more in Billing and payments in Developer Spaces.
Resource usage API
Use the new Export app resource usage API to access detailed resource usage data and integrate it with your own reporting or third-party tools.
Commerce APIs
The offering ID for Forge App Hosting is 59f614dc-f9d0-4fad-924d-bb9d707d33ab. Commerce public APIs can be leveraged for more information. These APIs can help extend your usage insights to cost-based insights.
Expanded site-level usage visibility
The previous limit of viewing only the top 20 sites for resource usage has been removed. You can now view all sites that generated usage for a resource in the developer console.
Key documentation updates
Forge Service Level Agreement is now available.
The Atlassian Developer Terms and Forge Terms have been updated with Payment, Billing and SLA details.
To share feedback on these changes, select “Give feedback” in the “Get help” section at the top right of the developer console.
The requestRemote bridge API now supports passing FormData in the body of the request.
For more details, refer to the documentation for requestRemote.
Forge’s native Node runtime now supports Node 24.
To use this runtime, set your app.runtime.name to nodejs24.x in the manifest file.
We’ve added the module bitbucket:workspacePersonalSettingsPage to Forge. You can use this module to build a custom workspace settings page. For more information, see Bitbucket workspace personal settings page.
Following the Preview release, the forge build command is now generally available. You can use this command to bundle and upload builds of your Forge app and deploy them across multiple environments.
App builds created using this command are also visible in the Forge Developer Console under Builds.
For more information, see the Forge build command documentation.
Following its EAP release, Forge bridge rovo API is now available in preview.
The Forge bridge rovo API contains the rovo.open method, which allows you to open the Rovo chat sidebar and create a new conversation with either a default or specified Rovo agent.
Run npm install @forge/bridge@latest on the command line to install the latest version of @forge/bridge and receive these changes.
For more information, see the Rovo documentation.
Bitbucket Data Center and Server 8.19.26, 9.4.14 and 10.1.2 bug fix releases are available now!
To see the issues resolved in these bug fix releases, go to:
Rate this page: