Atlassian developer changelog

Quotes reporting is now available via Marketplace reporting APIs. We're introducing Quotes reporting to the Atlassian Marketplace reporting APIs. Partners can now programmatically retrieve their accepted quotes and export quotes data in bulk.

You can now access accepted-quote data for your apps through the reporting APIs:

• List accepted quotes — a paginated list of accepted quotes for your apps, with filtering by product, creation date, acceptance date, and entitlement period.

• Quote details — line-level detail for a single quote (including schedules and discounts), looked up by quoteId and/or quoteNumber.

• Async export — initiate a bulk export of accepted quotes, poll its status, and download the resulting CSV/JSON file (recommended for large datasets).

The following endpoints are available for Quotes reporting.

Vendor (v2):

• GET rest/2/vendors/{vendorId}/reporting/quotes(link)

• GET rest/2/vendors/{vendorId}/reporting/quotes/details(link)

• POST rest/2/vendors/{vendorId}/reporting/quotes/async/export(link)

• GET rest/2/vendors/{vendorId}/reporting/quotes/async/export/{exportId}/status(link)

• GET rest/2/vendors/{vendorId}/reporting/quotes/async/export/{exportId}(link)

Developer-space (v3):

• GET rest/3/reporting/developer-space/{developerId}/quotes(link)

• GET rest/3/reporting/developer-space/{developerId}/quotes/details(link)

• POST rest/3/reporting/developer-space/{developerId}/quotes/async/export(link)

• GET rest/3/reporting/developer-space/{developerId}/quotes/async/export/{exportId}/status(link)

• GET rest/3/reporting/developer-space/{developerId}/quotes/async/export/{exportId}(link)

Key query parameters (list endpoint): productId, startDate, endDate, acceptedStartDate, acceptedEndDate, entitlementStartDate, entitlementEndDate, limit, offset.

Quote details: provide quoteId and/or quoteNumber (optionally entitlementNumber).

Async export: filter by createdStartDate/createdEndDate, acceptedStartDate/acceptedEndDate, entitlementStartDate/entitlementEndDate, and choose accept=csv or accept=json. At least one complete date range pair is required.

GET rest/3/reporting/developer-space/{developerId}/quotes?startDate=2025-01-01&endDate=2025-01-31

No action is required to keep existing integrations working.

If you want to consume quotes data:

• Use the vendor endpoints (/rest/2/vendors/{vendorId}/...) for vendor-scoped access, or the developer-space endpoints (/rest/3/reporting/developer-space/{developerId}/...) for developer-scoped access across all your apps.

• For large result sets, prefer the async export flow (initiate → poll status → download) rather than the synchronous list endpoint.

• New skill: forge-cost-optimizer – Analyzes your Forge app's resource usage and recommends optimizations to reduce invocation costs.

• New skill: forge-security-review – Performs automated security checks against common vulnerabilities and Atlassian best practices before deployment.

• New skill: forge-connector – Helps scaffold and configure connections between Forge apps and external services.

• Updated: forge-app-review – Now provides a lightweight release-readiness review covering permissions, manifest hygiene, and common deployment blockers.

• Codex support – Added Codex as an installation option for the plugin and individual skills.

• If you're using the Forge AI Plugin, update to the latest version to access the new cost optimizer and security review features.

• To install via Codex, follow the new Codex installation steps in the relevant skill or plugin docs.

We’ve released a preview of new modal sizing capabilities, giving you more control over how your app's modals appear and behave.

• Custom pixel sizes: You can now pass specific width and height values in pixels to define the exact dimensions of your modal.

• Runtime resizing: You can enable dynamic resizing by adding viewportSize: resizable to modal extension points in your manifest, or by passing resizable to the size prop in UI Kit and @forge/bridge modal.

What you need to do
As this feature is currently in preview, we encourage you to test these new configurations in your development environments:

1. For extension points: Update your manifest.yml to include the viewportSize: resizable attribute or viewportSize: { width, height } for relevant modules.

2. For UI Kit or Bridge: Update your modal calls to use supported css string values for width and height, or set the size prop to resizable.

For detailed implementation details, refer to the updated documentation:

• https://developer.atlassian.com/platform/forge/apis-reference/ui-api-bridge/modal/#modal

• https://developer.atlassian.com/platform/forge/ui-kit/components/modal/

• https://developer.atlassian.com/platform/forge/manifest-reference/modules/

As part of end of support for Connect app, we will be deprecating application property APIs.

When we reach Connect EOL, the following endpoints will be removed:

1. GET /repositories/{workspace}/{repo_slug}/commit/{commit}/properties/{app_key}/{property_name}

2. PUT /repositories/{workspace}/{repo_slug}/commit/{commit}/properties/{app_key}/{property_name}

3. DEL /repositories/{workspace}/{repo_slug}/commit/{commit}/properties/{app_key}/{property_name}

4. GET /repositories/{workspace}/{repo_slug}/properties/{app_key}/{property_name}

5. PUT /repositories/{workspace}/{repo_slug}/properties/{app_key}/{property_name}

6. DEL /repositories/{workspace}/{repo_slug}/properties/{app_key}/{property_name}

7. GET /repositories/{workspace}/{repo_slug}/pullrequests/{pullrequest_id}/properties/{app_key}/{property_name}

8. PUT /repositories/{workspace}/{repo_slug}/pullrequests/{pullrequest_id}/properties/{app_key}/{property_name}

9. DEL /repositories/{workspace}/{repo_slug}/pullrequests/{pullrequest_id}/properties/{app_key}/{property_name}

10. GET /users/{selected_user}/properties/{app_key}/{property_name}

11. PUT /users/{selected_user}/properties/{app_key}/{property_name}

12. DEL /users/{selected_user}/properties/{app_key}/{property_name}

We are updating the Marketplace Security Enforcement Policy to include new requirements for app lifecycle and maintenance. To ensure the Marketplace remains secure and trustworthy, all cloud apps must be actively maintained.

What's changing

To keep the Marketplace secure and trustworthy, every cloud app must be actively maintained. Apps that have not shipped a version update in more than 18 months will be considered unmaintained. These apps will be subject to review under the Cloud App Compliance program. While an unmaintained app is not automatically considered insecure, the 18-month mark serves as a mandatory lifecycle checkpoint. At this point, Atlassian will reassess whether the app continues to meet our security and compliance standards.

What you need to do

If your app is identified as unmaintained, you will be notified and given a defined window to either publish a compliant update or confirm your intent to maintain the listing.

Apps that are not brought back into compliance within that window may be hidden from the Marketplace and possibly subjected to actions detailed in our Marketplace Security Enforcement Policy

For apps with active installs, we will provide a transition period and notify affected customers before any removal. Limited, time-bound exceptions may be granted where justified.

For more details, see the Marketplace Security Enforcement Policy.

We've introduced a structured process for partners and Atlassian to jointly investigate security incidents affecting your app or the customer data it handles.

What's changing

• Log sharing for Forge apps: Atlassian can now share incident-scoped platform logs and app telemetry with you during an investigation. This provides the data you need to diagnose and resolve issues faster.

• A single reporting path: You can now report security incidents through the new developer support portal form. This form serves as the shared record for both you and Atlassian.

What you need to do

• Review the program overview page to understand eligibility and support levels.

• Ensure your security contact information is up to date in the partner account to ensure you are ready before an incident occurs.

Resource-restricted tokens are now available for all developers creating new 3LO apps.

When creating a new OAuth 2.0 (3LO) app via the Developer Console, you can now opt in to resource-restricted tokens. This ensures that access tokens issued for your app are scoped to only the specific Atlassian site a user explicitly selects during consent rather than granting broad access across all sites.

Forge SQL now inspects every query submitted by your app before it reaches the database. Queries that contain restricted functions, statements, or syntax are rejected with a new SQL_POLICY_VIOLATION error code before execution.

We’ve implemented this new policy to enforce the following:

• Stricter compliance with standard ANSI SQL syntax.

• Pre-emptive protection against SQL-based resource exhaustion and exploits.

• Stable, predictable performance across all Forge apps using SQL storage.

New error code: SQL_POLICY_VIOLATION

If your app submits a query that uses a restricted function or pattern, the @forge/sql package will return an error with a code, message, and suggestion field to help you resolve the violation.

Restricted functions and statements

The following are now monitored and may trigger rejection:

• Functions: SLEEP(), BENCHMARK(), COMPRESS(), UNCOMPRESS(), AES_ENCRYPT(), AES_DECRYPT(), SHA2()

• Statements: ALTER USER, LOCK TABLES, USE <table>

• Patterns: Unsupported optimizer hints, SET GLOBAL/SET INSTANCE, most SHOW statements, SQL-level PREPARE/EXECUTE/DEALLOCATE PREPARE, and multi-statement queries.

A subset of SET, SHOW, USE and optimizer hints remain permitted. See the SQL query policy documentation for the full allowlist.

What you need to do

• Review your queries: If your app uses any restricted functions or syntax patterns, those queries will now be rejected at runtime.

• Update error handling: Check for errorCodes.SQL_POLICY_VIOLATION alongside existing error codes to handle rejections gracefully.

If your app requires a restricted function for a valid use case, request an exemption through the Developer Support portal with your app.id, the query, and the use case.

Forge connectors built on the @forge/teamwork-graph SDK can now use Orchestration - a platform-managed scheduling and execution layer that runs background ingestion work without an external scheduler or cron.

We’re enhancing the jira:uiModifications module to support interactions with different user types in Jira.

Apps with UI Modifications that need to work for anonymous users must explicitly declare this in the app manifest using the unlicensedAccess attribute.

This change will take effect on Jun 29, 2026. We recommend that you deploy an update to your app before this date to avoid any interruption to your app’s functionality for anonymous users.

Add the anonymous value to the unlicensedAccess attribute for each jira:uiModificationsmodule that needs to execute for anonymous users in Jira.

For more information, see the guide on Access to Forge apps for unlicensed users.

From Monday Jun 29, 2026 onwards, UI Modifications modules will not be executed for anonymous users unless the module explicitly declares it.

You can now configure product event triggers and scheduled triggers to skip invocations for installations where your app is not actively licensed.

What's changing

By adding the appIsLicensed filter to your trigger modules in manifest.yml, the Forge platform will block trigger invocations for installations where the app's license is already inactive. This helps reduce unnecessary compute usage for unlicensed installations.

This change is specifically designed to address apps with existing inactive licenses (e.g., legacy entitlements that have lapsed). It is separate from the broader platform app suspension behaviour being explored in https://community.developer.atlassian.com/t/rfc-137-forge-app-suspension-behaviour/101092, which covers future suspension lifecycle handling.

This is an opt-in feature. Existing triggers are unaffected unless you explicitly add the filter to your manifest.

What you need to do

To enable this filtering, update your manifest.yml by adding the appIsLicensed: true filter to your trigger modules:

• Open your manifest.yml file

• Locate your trigger or scheduledTrigger modules

• Add the filter property with appIsLicensed: true

For more information, see the https://developer.atlassian.com/platform/forge/manifest-reference/modules/trigger/#filter-reference and https://developer.atlassian.com/platform/forge/manifest-reference/modules/scheduled-trigger/#filter-reference.

What’s changing
You can now enable guest access for the following Jira Forge modules:

• jira:customField

• jira:customFieldType

• jira:issuePanel

This update allows your apps to run for unlicensed users (guests) who have been invited to a single Jira space. By default, Forge apps only run for licensed Jira and Jira Service Management users.

What you need to do
To allow your app to serve unlicensed and guest users, add the unlicensedAccess property to the relevant modules in your manifest.yml file.

For detailed implementation steps, refer to the guide for unlicensed users.

As announced in Feb 5, 2026, we have removed the Bitbucket Cloud Connect addon linker APIs. These endpoints are no longer available.

The following REST API endpoints have been removed from Bitbucket Cloud:

• GET /2.0/addon/linkers

• GET /2.0/addon/linkers/{linker_key}

• GET /2.0/addon/linkers/{linker_key}/values

• PUT /2.0/addon/linkers/{linker_key}/values

• POST /2.0/addon/linkers/{linker_key}/values

• DEL /2.0/addon/linkers/{linker_key}/values

• GET /2.0/addon/linkers/{linker_key}/values/{value_id}

If you were using these endpoints, you must update your integrations to remove these calls as they will now return an error. For more information on the end of support for Connect on Bitbucket Cloud, please refer to the official announcement.

On 15 September 2026, the jiraServiceManagement:queuePage Forge extension point will stop loading on Customer Service Management (CSM) spaces in Jira.

What's changing

Apps using this module on CSM queues will stop rendering on that surface from the deprecation date. The module will continue to function as expected on standard Jira Service Management (JSM) spaces.

What you need to do

You should migrate to the dedicated replacement extension point, customerServiceManagement:queuePage, which is generally available from 15 June 2026.

• Replace jiraServiceManagement:queuePage with customerServiceManagement:queuePage in your app's manifest.yml.

• Review the manifest reference for the new module.

• Deploy your changes before the deadline.

Timeline

• 15 June 2026: customerServiceManagement:queuePage reaches GA.

• 15 June 2026 – 14 September 2026: Migration window.

• 15 September 2026: jiraServiceManagement:queuePage stops loading on CSM spaces.

If you cannot migrate in time, please contact Atlassian for case-by-case support.

The app migration platform will now automatically detect the correct migration listener to invoke if multiple are defined. This can be useful for defining different migration paths to different environments (i.e. commercial, isolated cloud and AGC) or if you would like to support migrations to one or more cloud apps.

To find out more, our documentation is available here