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.
The Teamwork Graph Consumption API is now moving into Preview, providing relationship-first querying across Atlassian Cloud objects and connected third-party tools.
What's changing
The Teamwork Graph API lets you query connected context across Jira work items, Confluence content, Loom videos and meetings, external development artifacts, Goals, and Teams using a unified GraphQL endpoint.
Key capabilities in this release include
Curated queries: Supported, typed GraphQL fields for common traversals (such as atlassianUserAssignedJiraWorkItems or confluencePageContributors) with built-in Relay cursor pagination (first, after). No query registration is required.
Persisted Cypher queries: Custom graph traversals registered ahead of time to receive a persistent query key (queryKey), which you execute at runtime via the customQuery GraphQL root field.
Granular object-level scopes: Permissions now use fine-grained scopes following the read:graph:<object>:<product> pattern (such as read:graph:issue:jira and read:graph:page:confluence), giving site administrators precise control in Connected Apps.
What you need to do
Update your Forge app manifest.yml permissions to request the specific read:graph:<object>:<product> scopes required for your queries.
If your app currently uses ad-hoc runtime Cypher queries, migrate to typed fields in the curated queries documentation or register custom queries using the persisted Cypher queries guide.
What's changing
We've introduced new experimental REST APIs for managing space policies in Jira Cloud. Space policies allow site administrators to govern the creation and usage of fields and statuses in team-managed spaces, helping to prevent configuration sprawl and maintain instance health.
The following experimental endpoints are now available:
Viewing policies
GET /rest/api/3/policies — Get all policies
GET /rest/api/3/policies/project/{projectIdOrKey} — Get project policy state
GET /rest/api/3/policies/project/{projectIdOrKey}/rules — Get project policy rules
Applying policies to projects
POST /rest/api/3/policies/{policyId}/apply — Apply a policy to projects
POST /rest/api/3/policies/{policyId}/remove — Remove a policy from projects
PUT /rest/api/3/policies/project/{projectIdOrKey}/policies — Set the policies applied to a project
POST /rest/api/3/policies/project/{projectIdOrKey}/validate — Validate policy application to a project
What you need to do
Review the Jira Cloud space policy API documentation to understand the available methods and data structures.
Note that these APIs are currently experimental and may change without notice.
If you are building integrations that create fields or statuses, ensure you handle potential blocks when a space policy is active.
Rollout: progressive rollout by tenant IN PROGRESS
What's changing
We are updating the behavior of the Confluence Cloud REST API V1 content restrictions endpoints to ensure consistency between view and edit access. Previously, it was possible for a principal (user or group) to hold an update (Can edit) restriction without holding the corresponding read (Can view) restriction on content that had view restrictions applied.
After this change:
All principals will hold either only the read restriction (Can view) or both the read and update restrictions (Can edit).
If a principal holds both read and update restrictions, any API request to remove only the read restriction will result in a rejection.
To move content into an "edit restricted" state for these principals, you must request the removal of all read restrictions.
What you need to do
If your application manages content restrictions via the Confluence Cloud REST API V1, review your implementation to ensure:
When granting update access, you also include the read restriction for that principal.
Your logic for removing restrictions accounts for the fact that read access is now a prerequisite for update access.
What's changing
We are introducing new Confluence Cloud REST API v2 endpoints to manage content permissions and restriction states. These endpoints provide a consistent way to handle permissions across multiple content types, including pages, blog posts, databases, whiteboards, and folders.
The new endpoints are:
GET /wiki/api/v2/{content-type}/{id}/restriction-state: Retrieves the current restriction state of the content.
PUT /wiki/api/v2/{content-type}/{id}/restriction-state: Updates the restriction state (for example, to make content restricted or open).
GET /wiki/api/v2/{content-type}/{id}/permissions: Lists the specific permissions (read and update) applied to the content.
POST /wiki/api/v2/{content-type}/{id}/permissions: Adds new permissions for a user or group.
PUT /wiki/api/v2/{content-type}/{id}/permissions: Updates existing permissions.
DELETE /wiki/api/v2/{content-type}/{id}/permissions: Removes permissions.
What you need to do
If you are building new integrations or migrating from the V1 content restrictions API, we recommend using these new v2 endpoints.
What's changing
On Nov 30, 2026 Git requests authenticated using OAuth2.0 via the Git Credential Manager (GCM) will be blocked for versions prior to 3.0.0. This is caused by the lack of support for rotating OAuth refresh tokens, which have recently begun being enforced for Bitbucket’s OAuth 2.0 implementation. See: https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3052. Atlassian contributed changes to the open source project to include support for the rotating refresh token model, which was bundled in the v3.0.0 release (https://github.com/git-ecosystem/git-credential-manager/releases/tag/v3.0.1)
What you need to do
If | Action/s Required? |
|---|---|
You are NOT using Git Credential Manager | No action is required |
You ARE using Git Credential Manager configured with personal access tokens | No action is required |
You ARE using Git Credential Manager configured with OAuth2.0 | You must upgrade Git Credential Manager to a version 3.0.0 or higher by Nov 30, 2026 if you wish to continue to authenticate Git using this mechanism. Simply upgrading the version should ensure seamless authentication. Note: Impacted users will see a message after each git push operation prior to upgrade. |
Upgrade instructions
Follow the GCM documentation for operating system specific installation instructions herehttps://github.com/git-ecosystem/git-credential-manager/blob/main/docs/install.md.
Note: For Git For Windows (https://git-scm.com/install/windows) users, GCM is bundled. Git For Windows releases are tied to the upstream Git release - currently there is no available release which bundles the pre-requisite version of GCM. Until a new version is cut, please install a suitable version of GCM directly. These instructions will be updated with the required Git for Windows version once a suitable release is available.
Further details
If you want to learn more about the changes made in Git Credential Manager see:
We’re excited to announce that the below tools now support showing rich UI cards on Atlassian MCP V2.
Jira : getJiraIssue, editJiraIssue, createJiraIssue, transitionJiraIssue, and searchJiraIssuesUsingJql
Confluence : searchConfluence
NOTE: We are doing a steady rollout across all customers, and if you do not see these by Oct 23, 2026 , please reach out to support.
Dynamic modules, customer-managed egress, and customer-managed remotes are now generally available on the Forge platform.
Dynamic modules let a Forge app register and manage modules at runtime through the Dynamic Modules API, rather than declaring them statically in the manifest. These modules are available across Jira, Confluence, and Jira Service Management.
Customer-managed egress lets Atlassian administrators configure the external domains a Forge app may send data to.
Customer-managed remotes let Atlassian administrators configure the remote backends a Forge app may communicate with.
For more information, see Dynamic modules and Customer-managed egress and remotes.
These capabilities are not currently supported for Atlassian Government Cloud.
These capabilities follow their earlier Preview releases: Forge Dynamic Modules Preview and Customer-managed egress and remotes Preview.
What's changing
Forge display conditions for Jira and Jira Service Management (JSM) modules now support arrays under the and, or, and not logical operators.
Previously, manifest keys had to be unique at each level, which made it difficult to repeat the same condition type or group multiple logical expressions. With this update, you can use an array of condition objects to define complex visibility logic more easily.
For example, you can now structure your manifest to group conditions or repeat the same condition type:
1
2
3
4
5
6
7
8
displayConditions:
or:
- and:
- entityPropertyExists: { entity: user, propertyKey: a }
- entityPropertyExists: { entity: user, propertyKey: b }
- and:
- entityPropertyExists: { entity: user, propertyKey: c }
- entityPropertyExists: { entity: user, propertyKey: d }
What you need to do
No action is required for existing apps, as the previous syntax remains supported. If you want to simplify complex logic or repeat conditions in your Jira or JSM modules, you can update your manifest to use the new array-based syntax.
For more details and examples, see the Forge display conditions documentation.
We are reintroducing direct JQL query validation to the Search REST API (/rest/api/3/search/jql) specifically for queries that use custom JQL functions.
Previously, when the new Search REST API was introduced, JQL validation was moved exclusively to the parse endpoint (/rest/api/3/jql/parse). Based on developer feedback, we are bringing this capability back to the search endpoint for custom JQL functions.
If a JQL query containing custom JQL functions is invalid, malformed, or references unsupported functions or arguments, the search API will now return an immediate HTTP 400 Bad Request with detailed error messages. This change applies exclusively to custom JQL functions; native JQL queries and other general usages of the search endpoint remain unaffected and will continue to follow existing validation behaviors.
What you need to do
Simplify your integration: If your app uses custom JQL functions, you no longer need to make a separate pre-flight call to the JQL parse API (/rest/api/3/jql/parse) to validate these queries before searching.
Update error handling: Ensure your search API integrations are prepared to handle HTTP 400 Bad Request responses and can inspect the returned error messages when executing queries that include custom JQL functions.
Review documentation: For more information on constructing queries, refer to the Jira Search REST API documentation.
JQL searches that use user entity properties with the voter, watcher, or creator fields are being deprecated. If you maintain apps or custom integrations that rely on these searches, you must update your queries before support is removed to ensure your data remains searchable.
What's changing
Jira is deprecating support for user entity property searches on the voter, watcher, and creator fields.
Impact: After the removal date, any JQL queries or API requests attempting these searches will be rejected with an UnsupportedOperationException.
Note: User entity property searches for other fields, such as assignee and reporter, remain fully supported.
Deprecation date: November 16, 2026
What you need to do
Review your apps and integrations for user entity property searches on the deprecated fields and migrate them. Use custom fields when the data must be searchable through core JQL, issue entity properties when the data is issue-scoped, or app-managed storage when the data is application-specific and does not require native JQL support.
The visual refresh of the labelling system (which consists of our tag, lozenge, and badge components) is now available by default, both when using the components directly and in Forge UI Kit. The feature flag that previously controlled access to the refreshed look has been removed, so you no longer need to enable it to use the new appearance.
This follows our earlier announcement of the labelling system changes, when the refreshed look was available behind a feature flag.
Date label and Date dropdown trigger are also now generally available (GA). These new additions to the labelling system were introduced without a feature flag.
We’ve fixed an issue where remotes referenced in permissions.external.fetch.client only allowed the default base URL, causing browser requests to regional endpoints to be blocked by the content security policy (FRGE-2205)
You can now read your app’s remote installation region using remoteInstallationRegion in getAppContext(). Adding a client-fetch URL that already exists in fetch.backend now results in a minor version change. See app versioning.
Jira is updating how text-field queries using the =, IN, or NOT IN operators are handled. Previously, these operators required an exact match of the full field value. For example, textField = "urgent" would only match if the field contained exactly "urgent" and nothing else.
With this update, these operators now perform an exact phrase search. This means the query will match if the specified phrase appears anywhere within the text field, even as part of a longer string. This behavior is now consistent with using the ~ operator with escaped quotes (for example, textField ~ "\"urgent\"").
Key details of the new behavior:
Broader matching: textField = "urgent" now matches "urgent", "urgent issue", and "very urgent issue". Previously, it would have only matched "urgent".
Phrase integrity: For multi-word queries like textField = "alpha beta", Jira matches the exact phrase in that specific order. It will match "prefix alpha beta suffix" but will not match "beta alpha" or "alpha something beta".
Case-insensitivity: Matching remains case-insensitive (e.g., "Alpha Beta" matches "alpha beta").
Stemming: Text search still applies stemming, so a search for "run" may also match "running" or "ran".
List operators: textField IN ("alpha beta", "urgent") now matches values containing either exact phrase anywhere in the text.
What you need to do
If you use saved filters, dashboard gadgets, or automation rules that rely on = or IN for text fields, you should:
Review your JQL queries to ensure they still return the expected results. Because the matching is now broader (matching phrases within longer text rather than the full field value), you may see more results than before.
If you require a search that matches words in any order, switch to the ~ operator without escaped quotes (for example, textField ~ "alpha beta").
Update any internal documentation or training materials to reflect that = now functions as a phrase search for text fields.
Bitbucket Data Center 10.5 is available for upgrade!
The new release introduces the Bitbucket DC Model Context Protocol (MCP) server for AI coding agents, X.509 system commit signing, fair share throttling for Git hosting operations.
Rate this page: