Atlassian developer changelog

We are extending enforcement of Jira Cloud configuration limits to additional REST API operations. This aligns REST API behavior with the limits enforced through Jira’s administration experience and helps protect site performance and reliability. https://support.atlassian.com/jira-cloud-administration/docs/data-limits-and-guardrails/

What is changing?

Affected REST API operations will return HTTP 422 Unprocessable Entity when a request would exceed the applicable configuration limit. This includes attempts to add configuration entries when the relevant scope has already reached or exceeded its limit.

This introduces limit enforcement, not just a status-code change for requests that already failed. Some requests that previously succeeded will now be rejected with HTTP 422 when the enforcement applies.

The OpenAPI specifications for the affected endpoints have been updated to document this response.

Action required

Developers maintaining apps, integrations, scripts, or automation that use these endpoints should:

• Update error handling to recognize HTTP 422 as a possible response for configuration-limit violations.

• Inspect the response body to identify the configuration-limit violation and provide administrators with guidance for resolving it.

• Avoid automatically retrying the same request without addressing the underlying limit. Reduce configuration usage or adjust the operation so it stays within the applicable limit before retrying.

Affected endpoints

Rollout

We plan to begin rolling out this change on 11–12 November 2026 as the planned rollout-start window. Once enabled for a site, affected Jira Cloud platform REST API operations will return HTTP 422 Unprocessable Entity when a request would exceed an applicable configuration limit.

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

1. 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.

2. 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.

3. Provide a migration URL. Customer-facing notices will direct customers to your app-specific guidance in place of the default Atlassian guidance.

4. 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.

We’re introducing a set of visual refinements to Atlassian UI to reduce visual noise and make interfaces feel calmer and easier to scan. These changes are behind the platform-dst-tokens-finesse feature flag and will be enabled as part of the upcoming rollout, and we’re sharing an early heads-up so you can prepare your apps.

What’s changing?

• Neutral selected states: Selected backgrounds will move from blue to a neutral fill, keeping selections clear while reducing competing emphasis. Keyboard focus indicators will remain blue.
  
  

   

• Lighter headings: ADS heading weights will change from Bold (653) to Semibold (600), creating a lighter appearance.
  
  

   

• Subtler search inputs: Search inputs will have lighter borders, with slightly darker placeholder text and search icons for improved legibility.
  
  

What should Marketplace partners review?

Please review how your app’s UI sits alongside these changes, particularly where you use custom styling or override ADS defaults:

• Selected states: Review hardcoded blue backgrounds and custom overrides. Use semantic selection tokens, such as color.background.selected, where appropriate.

• Typography: Check heading hierarchy and readability, especially where your app sets its own font weights.

• Search and accessibility: Review custom search inputs and check selection visibility, keyboard focus and readability in both light and dark themes.

Refer to the Atlassian Design System documentation for component and token guidance.

We’re extending the retirement date for the Cloud Fortified Apps (CFA) badge to January 31, 2027, aligning it with the Connect end of support date.

We’ve heard your feedback that you need more time to migrate from Connect to Forge and prepare for Atlassian Enterprise Certified (AEC). This extension gives you additional time to work toward AEC eligibility while retaining the Cloud Fortified badge customers rely on during the transition.

• Existing Cloud Fortified apps can retain their badge until January 31, 2027, provided they continue to meet Cloud Fortified requirements.

• AEC requirements remain unchanged. This extension does not grant AEC status or waive any eligibility requirements.

1. Review the https://developer.atlassian.com/platform/marketplace/atlassian-enterprise-certified-program/

2. Continue your migration from Connect to Forge to meet the AEC eligibility requirements.

3. Ensure your app continues to meet https://developer.atlassian.com/platform/marketplace/cloud-fortified/ to retain the badge until the new retirement date.

A new jira:entityPropertySet module type is now available for Forge apps. It lets you bundle multiple entity properties under a single module, with no limit on the number of properties.

Previously, each entity property required its own jira:entityProperty module, with a maximum of 100 indexable values per app. The new jira:entityPropertySet module removes this limit — apps can now declare hundreds or thousands of entity properties under a single module.

Declare the module in your manifest.yml:

• JQL search via searchAlias works the same way

• Required permissions: read:jira-work and write:jira-work

• Platform-wide limit of 1,000 searchable entity properties per entity type, shared across all apps on the tenant

jira:entityPropertySet module reference

• FRGE-2171

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.

Organization admins can now let service accounts connect to the Atlassian MCP server using OAuth 2.0 client credentials. Pipelines and scheduled jobs get an access token without a browser sign-in, and you don’t need to turn on API token authentication for your organization.

To get started with this change:

1. In Atlassian Administration, select your organization if you have more than one.

2. Go to Directory, then Service accounts, and create a service account. Give it app roles only on the sites it needs.

3. Select the service account, then Create credentials and OAuth 2.0.

4. Select the Product *:agent-interface scopes, plus read:me and read:account. You can’t change scopes after you create the credential.

5. Copy the client ID and client secret. The secret is shown only once.

6. In your workflow, exchange the client ID and secret for an access token, then send it to https://mcp.atlassian.com/v2/mcp as a Bearer token. Access tokens are valid for 60 minutes, so request a new one before the current one expires.

To create the credential, see Create an OAuth 2.0 credential for service accounts.

The Atlassian Guard external sites policy now applies when your managed users connect to Atlassian sites through the Atlassian MCP server. You can block external Atlassian sites or allow only selected partner sites, while your own organization’s sites stay available. There’s no separate MCP setting to turn on.

To get started with this change

1. Go to Atlassian Administration. Select your organization if you have more than one.

2. Select Security, then Device security, then External sites.

3. Create a draft policy that allows specific external sites or blocks all external sites.

4. Activate the policy.

If you already have an active external sites policy, it now applies to MCP. You don’t need to do anything. The policy requires Atlassian Guard Standard. Learn more: Manage access to external sites.

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

1. Check that your apps stay within these new limits.

2. If you store large values in environment variables, move them to Forge storage.

3. If your app currently exceeds these limits in any environment, update your variables by Tuesday, May 11, 2027.

4. 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

1. Update @forge/bridge in your app’s frontend directory:

   1 npm install @forge/bridge@latest

2. Review the permissions in your manifest.yml and declare the scopes required for the objects your queries access. See the Teamwork Graph scopes reference.

3. 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:

1. Ensure your macro is configured as a bodied macro in manifest.yml with layout: bodied.

2. 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

1. Update your app code to ensure all objects are hashed using the SHA256 algorithm.

2. If you are manually passing checksumType to createUploadUrl or createPublicUploadUrl, update the value to 'SHA256'.

3. 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:

1. Locate your jira:customFieldType module.

2. Under the view.formatter property, add allowPrerender: true.

For more details on implementation, see the Pre-rendering formatter output on Jira issue view documentation.