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 will be introducing in-product migration messaging for Connect EOS. Apps that have not declared an intent to migrate to Forge, or have declared an intent of no or undecided will be the cohort of this rollout.
Rollout timeline
In approximately two weeks: Messaging will roll out to environments enrolled in the Developer Canary Program, giving partners an opportunity to preview and test the experience.
One week after the Canary rollout begins: We’ll begin a gradual rollout to production instances throughout the month of December.
Which apps are affected?
Apps that have declared a migration intent of no in the connectToForgeMigration module.
Apps that have declared a migration intent of undecided in the connectToForgeMigration module.
Apps that have not declared the connectToForgeMigration module. This includes apps with a Connect descriptor.
What you need to do
Add the migration module. If you haven’t already, add the Connect to Forge migration module to your Forge manifest for each major version of your app.
Declare your migration intent. Set your intent to accurately reflect your plans:
yes: Messaging will not appear in-product before Jan 31, 2027, but will remain visible on the Connected Apps page.
no or undecided: Messaging will appear both in-product and on the Connected Apps page.
Provide a migration URL. Customer-facing notices will direct customers to your app-specific guidance in place of the default Atlassian guidance.
Preview the experience. Use an instance enrolled in the Developer Canary Program to review the messaging before the production rollout.
Please refer to our documentation on what users see in your app.
What’s Changing
We're expanding Ecoscanner with new automated security checks for Marketplace Forge apps to ensure compliance with our Security Requirements for Cloud Apps. These checks will be released periodically before December 31, 2026.
The new checks include:
Arbitrary code execution: Detects untrusted input reaching dynamic code execution (e.g., eval) in Forge functions (Requirement 8, Critical Severity).
End-of-life Node.js runtimes: Flags apps using Node.js runtimes that have reached end-of-life (Requirement 10, Critical Severity).
Atlassian API token usage: Detects apps authenticating to Atlassian APIs using user API tokens instead of app-based authentication (Requirement 11, Critical Severity).
Secrets in logs: Detects sensitive data (e.g., credentials) written to application logs via console.log or similar (Requirement 5, High Severity).
SQL injection: Detects user input interpolated directly into Forge SQL queries instead of using query parameters (Requirement 8, High Severity).
TLS and HSTS on Forge remotes: Verifies that remote backends accept only TLS 1.2+ and return an HSTS header with a max-age of at least one year (Requirement 3, Medium Severity).
What You Need to Do
As these scanners go live, findings will be reported to you via AMS tickets in ecosystem.atlassian.net.
To account for the holiday period, we are providing an additional 30 days beyond the standard Security Bug Fix Policy for findings from High or Medium severity checks during this initial launch. Standard resolution timeframes will apply to all findings starting January 1, 2027.
More details on how these checks work will be included in the Ecoscanner documentation as they are released. If you have questions, please contact Developer Support.
Following the temporary block announced in https://developer.atlassian.com/platform/marketplace/changelog/#CHANGE-3353, Commerce Pricing APIs are now available again.
Partners can resume using the Commerce Pricing API to fetch pricing information and update app pricing.
There are few updates on how to use these APIs, please refer to the updated guide, see https://developer.atlassian.com/platform/marketplace/marketplace-app-pricing-api/.
Thank you for your patience while this temporary block was in place.
We're introducing limits on the number and size of Forge environment variables and secrets to ensure the stability and reliability of the service for all apps.
What’s changing
The following limits now apply to each environment of your app, and are checked when you run forge variables set and forge deploy:
Plain variables: up to 50 per environment.
Encrypted variables (secrets): up to 10 per environment.
Variable value size: up to 3,072 bytes (3 KB) for both plain and encrypted variables. Size is measured before encryption.
Variable key length: up to 128 characters.
What you need to do
Check that your apps stay within these new limits.
If you store large values in environment variables, move them to Forge storage.
If your app currently exceeds these limits in any environment, update your variables by Tuesday, May 11, 2027.
If you require a higher limit for a specific use case, reach out via the developer support portal.
For more details, see the Environment variable limits documentation.
What’s changing
The requestTeamworkGraph() Forge bridge API has moved from the Early Access Program (EAP) to Preview.
You can query Teamwork Graph directly from UI Kit and Custom UI frontends using @forge/bridge, without routing requests through a Forge backend function.
Requests run on behalf of the current user and respect their permissions. Your app must also declare the scopes required by each query.
What you need to do
Update @forge/bridge in your app’s frontend directory:
1
npm install @forge/bridge@latestReview the permissions in your manifest.yml and declare the scopes required for the objects your queries access. See the Teamwork Graph scopes reference.
Use requestTeamworkGraph() to execute queries from your frontend.
For implementation details, see the requestTeamworkGraph reference and Teamwork Graph API guide.
What's changing
You can now customise the background of the platform-managed ADF renderer iframe in Forge Custom UI bodied macros. By using the new background option in view.createAdfRendererIframeProps(), you can ensure your rendered content blends seamlessly with your app's design and the Confluence theme.
Supported values for the background option include transparent, Atlassian Design System background tokens and hex colour codes.
What you need to do
To use this feature, update your @forge/bridge package to the latest version and update your macro's implementation:
Ensure your macro is configured as a bodied macro in manifest.yml with layout: bodied.
Update your call to view.createAdfRendererIframeProps() to include the background property
For more information, see documentation.
Forge Object Store is deprecating the allowed values in the checksumType field in the createUploadUrl and createPublicUploadUrl methods in @forge/object-store package and in GeneratedMetadata as part of objectStore API in the @forge/bridge package . All checksums are now required to use the SHA256 algorithm.
Starting December 10, 2026, any requests using other checksum types (such as SHA1, CRC32, or CRC32C) will be rejected with an HTTP 400 Unsupported Media Type status and the error code CHECKSUM_TYPE_UNSUPPORTED.
We will be releasing a new major version of the @forge/object-store package that removes all other types from the checksumType field except for SHA256.
What you need to do
Update your app code to ensure all objects are hashed using the SHA256 algorithm.
If you are manually passing checksumType to createUploadUrl or createPublicUploadUrl, update the value to 'SHA256'.
Upgrade to the latest major version of @forge/object-store once available to align with the new API signature.
For more details on how to implement SHA256 checksums, refer to the Forge Object Store API documentation.
If your app currently uses a different checksum type and you cannot migrate within the 1-month window, please reach out via an ECOHELP ticket.
The custom field context default value REST APIs deprecation has been extended to July 2027. This extension provides additional time to migrate as we adjust the timelines for supporting multiple default values per context.
Updated deprecation timeline:
November 4 2026: New GET /rest/api/3/field/{fieldId}/context/defaultValues endpoint available for testing.
November-December 2026: Early access begins for multiple default values per context and the new PUT /rest/api/3/field/{fieldId}/context/defaultValues REST API. You can sign up for early access via this form.
January 2027: GA launch of multiple default values per context and the new PUT /rest/api/3/field/{fieldId}/context/defaultValues REST API.
July 2027: The existing (deprecated) default values APIs will be removed.
What's changing
You can now use the view.formatter.allowPrerender manifest property to display a Forge custom field's formatter output as pre-rendered content on the Jira issue view. This content is shown while the field's custom read view is loading, providing a faster and more seamless experience for users.
Automatic pre-rendering: Fields without a custom issue-view renderer are pre-rendered by default.
Opt-in pre-rendering: Fields that use a view.function or view.resource renderer can now opt in by setting allowPrerender: true in the manifest.
What you need to do
To enable pre-rendering for your custom field, update your manifest.yml file:
Locate your jira:customFieldType module.
Under the view.formatter property, add allowPrerender: true.
1
2
3
4
5
6
7
8
modules:
jira:customFieldType:
- key: my-custom-field
name: My Custom Field
view:
resource: main
formatter:
allowPrerender: true
For more details on implementation, see the Pre-rendering formatter output on Jira issue view documentation.
Summary
Support inline-bodied layouts for Confluence Forge macros
Description
Confluence Forge macros now support layout: inline-bodied for macros with rich-text bodies that should render inline with surrounding text. This layout supports both UI Kit and Custom UI, including macros migrated from Connect.
What you need to do
Use Forge CLI 14.0.0 or later.
Set layout: inline-bodied on the relevant macro module in your manifest.yml.
If you are migrating a Connect macro with bodyType: rich-text and outputType: inline, apply this layout to the corresponding Forge macro.
Layout behavior
Macros appear as blocks while editing, this is the default behavior from Confluence Data Center and the Legacy Editor. Inline presentation in view mode requires a single paragraph of inline-compatible content. Multiple paragraphs or block elements, such as tables, lists, and headings, cause the macro to render as a block.
Export behavior depends on the export context and the content returned by your adfExport function. See the macro reference for supported behavior and requirements.
Documentation
Forge apps can now make online and offline calls on behalf of unverified user accounts using user impersonation including invocations from Forge functions and Forge Remote.
Online calls use the invoking user's context, while offline calls can act on behalf of a specified unverified user asUser(accountId) where supported.
Existing Forge app permissions, product permissions, and API-specific access controls continue to apply. This change does not enable anonymous-user access.
This includes support for unverified external customer accounts in Jira Service Management (such as email-created portal customers with qm: account IDs), as well as unverified Atlassian accounts
Atlassian MCP now supports Claude-issued Managed Auth, enabling Enterprise-managed authentication (EMA) / Cross App Access (XAA) directly from Claude without a dependency on an additional IdP.
For more details on how to get started, please review the Configure enterprise-managed authentication guide.
Bitbucket Data Center and Server 9.4.27 and 10.2.9 bug fix releases are available now!
To see the issues resolved in these bug fix releases, go to:
Following our deprecation notice of the 'draft' parameters on workflow rule APIS on Apr 22, 2026
As of Nov 2, 2026, the ability to filter on and modify draft workflows has been removed from the Workflow transition rules APIs. Calls that include the draft parameter now return an HTTP 400 (Bad Request) response and WorkflowId objects will no longer include the draft attribute.
Forge storage data residency moves no longer cause host product downtime
Until now, moving an app's Forge-hosted storage to another region meant taking its host product offline. That happened even when the host product had already moved.
Now, only the app installation being moved goes offline. The host product, and any other Atlassian product the app is linked to, remains fully available throughout the move.
What's affected while the app installation is offline
Storage, functions, and UI are unavailable: Calls to Forge-hosted storage, backend function invocations, resolver-driven UI, and dynamic component updates are blocked.
Upgrades and uninstalls are paused: Major version upgrades and uninstalls can't run until the move is finished.
Product events are queued, not lost: Atlassian product events sent to the app during the move are held and delivered automatically once the move completes.
This change applies automatically to all apps that use Forge-hosted storage
Rate this page: