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.
As per our previous announcement, admin-facing Connect end-of-support (EOS) migration messaging on the Connected Apps page is now gradually rolling out to production instances for apps that have declared a migration intent of ‘yes’.
Apps that have declared connectToForgeMigration with a migration intent of "yes"
The following app categories have already been rolled out to receive admin-facing messaging as per our previous changelog:
Apps that have declared connectToForgeMigration with a migration intent of "no"
Apps that have declared connectToForgeMigration with a migration intent of "unsure"
Apps that have not adopted the connectToForgeMigration module
Apps without a Forge manifest (i.e., Connect apps)
Adopt the connectToForgeMigration module in your Forge manifest for each major version of your app (https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-to-forge-migration-module/).
Declare your migration intent as this determines which cohort your app falls into and when messaging appears.
Provide a migration URL. This URL will be surfaced directly in customer-facing notices, replacing the default Atlassian messaging with your app-specific guidance.
Exemptions
Apps that are blocked by an accepted Connect EOS FRGE ticket will be exempt from customer messaging until one month past the delivery date of the blocking feature. This exemption list is determined exclusively by partners who have submitted a Connect EOS Submission request on these accepted tickets, providing a valid use case and explanation. If an app utilises an affected feature but has not submitted a Connect EOS submission, it will not be exempted from this messaging.
For the full customer-facing experience (including more information on what admins will see), please visit the documentation here. This page will also be shortly updated to capture our rollout approach.
We’re excited to share that a new version of Atlassian Rovo MCP is now available. This release introduces some significant changes including:
Support for new products - Loom, Goals, Projects, Team, Focus, Talent and Bitbucket.
New and improved Jira and Confluence tools, introducing support for attachments, whiteboards, databases, sprints and more.
More details about new and available tools are available here.
The new Atlassian Rovo MCP endpoint is now available at https://mcp.atlassian.com/v2/mcp and can be utilised today. Existing plugins and connectors on third-party platforms are being updated and may require you to re-add the plugin/connector for some clients.
On Mar 1, 2027 any existing utilization of v1 will automatically start to expose and utilize v2 tools. Any incompatible clients will need to clear cached clientIds or .well-known credentials to support continued authentication.
Customers utilising MCP Gateways can expose a flat list of tools by utilising the https://mcp.atlassian.com/v2/mcp?tools=all endpoint. tools/list will return tools paginated as 50 tools per page.
Bitbucket Data Center and Server 9.4.24, 10.2.7 and 10.4.3 bug fix releases are available now!
To see the issues resolved in these bug fix releases, go to:
In https://developer.atlassian.com/changelog/#CHANGE-3253, we announced that Forge custom fields (FCF) of type object can now render a rich custom edit experience in Jira's bulk edit. At that time, issue and project details were not available in the extension context during issue-bulk-edit, and we recommended using renderContext === 'issue-bulk-edit' to detect this case and render a fallback UI.
This limitation has now been removed. Issue and project context is now available in your app's extension context during bulk edit. You can use this context to make more informed decisions about the UI or the options you display.
If you previously added a fallback UI for the issue-bulk-edit render context, you can now update your app to use the available issue and project context instead.
Review the updated https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field/#extension-data:~:text=module%20is%20rendered.-,issues,-issue%5B%5D for details on the context shape.
No action is required if your edit experience does not depend on issue or project context.
Forge Frontend logging is now available in Early Access Program (EAP). This feature is supported for both UI Kit and Custom UI across all environments, including production. It captures console.error, uncaught exceptions, and unhandled promise rejections.
What's changing
Direct frontend observability: You can now view platform logs, custom log errors, and exceptions from your app's frontend directly in the Forge Developer Console and CLI.
Log export support: Frontend logs are accessible via the Export app logs API and Point to Point Logs Export.
Customer-controlled logging: Frontend logs are accessible when customers have provided consent to share app logs in admin.atlassian.com.
No billing during EAP: Frontend logs generated during the EAP period will not be charged.
What you need to do
Sign up for the EAP: Submit a request via the EAP form to enable this capability for your apps.
What's changing
We fixed an issue where the ttl returned for Forge Remote offline user impersonation tokens could incorrectly report 30 minutes, even though the token remained valid for up to four hours.
The returned ttl now accurately reflects the token’s remaining validity. This change only affects the reported value and does not alter the actual token lifetime.
What you need to do
If your app uses a fixed 30-minute token-refresh workaround, update it to use the returned ttl value from the offlineUserAuthToken mutation. This allows your app to cache it longer and refreshes tokens less often than previously.
We are removing support for anonymous (unauthenticated) users from the Forge Feature Flags Client SDK (FeatureFlags in @forge/bridge). Starting December 1, 2026, the Client SDK will no longer evaluate feature flags when no authenticated user is present.
Currently, the Client SDK can be initialized even without a logged-in user (i.e., when no accountId is available). After this change, FeatureFlags.initialize() will only function for authenticated users with a valid Atlassian account. If your app calls initialize() without an accountId in the user's identifiers, the SDK will not return evaluated flag values and will fallback to default values.
You are affected if your Forge app meets both of these conditions:
Uses the Feature Flags Client SDK (FeatureFlags from @forge/bridge)
Allows anonymous access (e.g., your app module has unlicensedAccess enabled and you serve users who are not logged in)
If your app only serves logged-in users, no action is needed.
Option A — Use a default value for anonymous users
Before calling initialize(), check whether an accountId is available. If not, skip initialization and use a hardcoded default for your feature flag logic:
1
2
3
4
5
6
7
8
9
const { accountId } = await view.getContext();
if (accountId) {
const featureFlags = new FeatureFlags();
await featureFlags.initialize(user, config);
const enabled = featureFlags.checkFlag("my-flag", false);
} else {
// Anonymous user — use default behaviour
const enabled = false;
}Option B — Move flag logic to the server-side SDK
If you need to control behaviour for anonymous users, use the https://developer.atlassian.com/platform/forge/feature-flags/feature-flags-sdk/ in a resolver. The server SDK supports targeting by installContext (site-level), which does not require a user identity.
Deprecation notice issued | Sep 2, 2026 |
End of support (breaking change) | Dec 1, 2026 |
The deprecation period is 90 days. During this time, the existing behaviour will continue to work, but you will see deprecation warnings in the developer console.
We are stopping submissions for the Cloud Fortified App (CFA) program. Starting September 1st, we will no longer accept new CFA submissions.
CFA annual reviews will also no longer be required from September 1st. The CFA program will be retired on 31st December, 2026.
The good news: the Atlassian Enterprise Certified (AEC) program is coming, and submissions will open around the end of September.
In the meantime, here's how to get ready:
Review the full list of AEC requirements here: https://developer.atlassian.com/platform/marketplace/atlassian-enterprise-certified-program/#atlassian-enterprise-certified-program
Audit your current security, privacy, accessibility, and compliance posture against the new criteria
Get your trust center, documentation and evidence in order, so you're ready to submit as soon as the window opens
We'll share more details on the submission process and timeline ahead of the September opening. Stay tuned.
We’re updating the invocation rate limits for Forge apps to support larger-scale apps and platform stability.
What’s changing
The invocation rate limits for user-led invocations (UI and web triggers) are being updated to the following values:
Per app installation: The limit is changing from 5,000 requests per minute (RPM) to 300 requests per second (RPS) or 7,000 RPM (whichever is hit first).
Per environment: The previous global limit of 30,000 RPM is being removed to provide more flexibility for apps with large numbers of installations.
Per user: The limit remains unchanged at 1,200 RPM.
What you need to do
If your app frequently performs high-burst activities, you may need to implement retry logic or optimize your function calls to stay within the 300 RPS threshold.
Retry logic can be implemented using:
The rateLimitProperties field returned from Forge bridge invoke
Web trigger rate limiting response headers
For implementation examples and more details, see the Forge invocation limits documentation.
Following the deprecation of the Marketplace V1/V2 APIs (https://developer.atlassian.com/platform/marketplace/changelog/#CHANGE-2117), the marketplace-client-java library will be restricted from use in third-party plugin development.
Plugin vendors should migrate to the https://developer.atlassian.com/platform/marketplace/rest/v4/intro/#about for direct integration.
Affected product versions -
Jira 12
Confluence 11
Bamboo 13
Bitbucket 11
Crowd 13
The Bulk fetch issues API (POST /rest/api/3/issue/bulkfetch) now supports a maximum of 1000 issues in a single request, up from the previous limit of 100. This higher limit is available for requests optimized for efficient processing. https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/1-000-Issues-One-Call-Bulk-Fetch-Gets-a-10-Boost/ba-p/3281867
What's changing
To qualify for the 1000-issue limit, your request must meet the following criteria:
Explicit field selection: You must explicitly name at least one field to include. Wildcards like *all or *navigable, and requests containing only exclusions (e.g., -description), are not eligible.
Field count: No more than 100 fields can be explicitly included.
Single-value fields only: Included fields must not return multiple values (e.g., comment, worklog, or attachment are excluded).
Restricted expands: The expand parameter must not include changelog, editmeta, operations, renderedFields, transitions, or versionedRepresentations.
What you need to do
No action is required if you wish to continue using the existing 100-issue limit. To take advantage of the 1000-issue capacity:
Update your request payload to explicitly list the specific fields you need.
Remove any multi-value fields or restricted expand parameters.
Increase your batch size up to 1000 issueIdsOrKeys.
If you require multi-valued data or changelogs for a large set of issues, we recommend splitting the work: use one 1000-issue call for "cheap" fields and separate, narrower calls for complex data. For changelogs, use the Bulk fetch changelogs endpoint to avoid the 40-item cap imposed by expand=changelog.
For more details, see the Bulk fetch issues reference documentation.
We’ve added a new API to allow callers to raise an existing issue on a CSM support site.
API callers can now share an existing issue to a support site for customers to see. The Summary and Description of the provided issue are shared with the customer on the support site.
You can now manage web trigger URLs programmatically from within your Forge Container Services environment. These new REST API endpoints provide parity with the @forge/api package and the Forge CLI, allowing your container-based apps to create, list, and delete web trigger URLs.
What's changing
We’ve added the following HTTP endpoints to the Forge Container Services REST API:
POST /forge/webtrigger/url: Create a new web trigger URL or retrieve an existing one.
GET /forge/webtrigger/urls: Retrieve all web trigger URLs associated with the app.
DELETE /forge/webtrigger/url: Delete a specific web trigger URL.
These endpoints enable containerized apps to handle their own web trigger lifecycle dynamically without relying on external CLI commands.
What you need to do
If your container-based app requires dynamic web trigger management, you can start using these endpoints immediately. Refer to the Forge Container Services REST API documentation for detailed request and response schemas.
What's changing
We have removed the limitation on the number of sites for which you can retrieve logs using the Export app logs API. Previously, the API was limited to returning logs for a maximum of 3,500 sites. This restriction has been lifted, allowing you to export logs across all sites where your app is installed and log sharing is enabled.
What you need to do
No action is required to benefit from this change. If you were previously limited by the 3,500-site threshold when polling for logs across your entire install base, you will now receive logs for all eligible sites automatically.
For more information on how to use the API, refer to the Export app logs documentation.
The Global Statuses Beta for team-managed spaces is now live. As previously announced, this feature allows global (site-wide) statuses to be added to team-managed workflows.
To try it, enable the feature via Jira Labs. Once enabled:
Workflow create and update APIs support global statuses in team-managed workflows.
Space templates will create workflows with global statuses by default.
Global statuses may appear in workflow read responses for team-managed spaces.
Rate this page: