We are deprecating the workflowId field in the webhook payloads sent to Connect workflow Post Functions. This field now returns a placeholder value, and will be removed after 31 July 2027.

The workflowId is an invalid value and may lead to bugs in your applications if used. It references an internal identifier that does not correspond to a workflow and cannot be mapped to any workflow in our public APIs.

If you are using workflowId, you should instead use workflowName or workflowEntityId, both of which contain values that can be used to correctly identify workflows.

We are deprecating the workflowId field in the webhook payloads sent via the Trigger a webhook post function in Jira workflows. This field now returns a placeholder value, and will be removed after 31 July 2027.

The workflowId is an invalid value and may lead to bugs in your webhook handlers if used. It references an internal identifier that does not correspond to a workflow and cannot be mapped to any workflow in our public APIs.

If you are using workflowId, you should instead use workflowName or workflowEntityId, which contains a value that can be used to correctly identify workflows.

We’re adding the workflowEntityId to webhook payloads sent to Connect applications to trigger post functions - this ID can be used to perform workflow operations or query data using the Workflow Rest APIs

We’re adding the workflowEntityId to webhook payloads that are sent as part of workflow post function execution - this ID can be used to perform workflow operations or query data using the Workflow Rest APIs

As per our previous announcement, we will be progressing admin-facing migration messaging on the Connected Apps page from the Developer Canary Program to production instances. This rollout will begin in approximately two weeks.

The following app categories will receive admin-facing messaging:

• 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)

Apps that have declared connectToForgeMigration with an intent of "yes" are estimated to begin receiving admin messaging in mid-August. We will provide another changelog entry at least 2 weeks before that change proceeds.

End-user messaging will not be included in this initial rollout. When ready, we'll follow the same approach:

• Release to Developer Canary tenants first for early testing

• Roll out in staggered cohorts

• Provide at least 2 weeks advance notice via the Forge changelog before each rollout stage goes live

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

2. Declare your migration intent as this determines which cohort your app falls into and when messaging appears.

3. Provide a migration URL. This URL will be surfaced directly in customer-facing notices, replacing the default Atlassian messaging with your app-specific guidance.

4. Preview the experience now using the Developer Canary Program. Customer messaging is already live on canary tenants. Install your app on a canary instance, navigate to the Connected Apps page, and confirm your migration URL renders as expected before the production rollout reaches your cohort.

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.

We've added a new set of public REST API endpoints that let you migrate Confluence spaces from the legacy granular space permission model to role-based access control (RBAC) using space roles.

Confluence spaces historically used 14 granular permissions (e.g. Add page, Delete attachment, Set permissions) assigned directly to users and groups. This checkbox-based model is difficult to audit, bulk-manage, and keep consistent across hundreds of spaces.

Confluence is replacing this with role-based access control (RBAC), where each principal (user, group, or app) is assigned a single space role (e.g. Admin, Collaborator, Viewer) that bundles the relevant permissions together.

These endpoints are the programmatic migration path: they let Confluence admins convert existing granular permission grants into equivalent role assignments — in bulk, without manual remapping — and are designed to be called from scripts or admin tooling.

All endpoints are under /wiki/api/v2/space-permissions/transition:

• GET /combinations — List a space's permission combinations that don't yet map to a role

• POST /combinations — Generate the permission combinations for a space

• POST /role-assignments — Bulk assign space roles to users/groups based on their existing permission combinations

• POST /access-removals — Bulk remove legacy permission combinations after transitioning to roles

• GET /tasks/{taskId} — Check the status of a transition task

• read:configuration:confluence — for the GET endpoints

• write:configuration:confluence — for the POST endpoints

Calling these endpoints requires Confluence site admin permission.

1. POST /combinations — compute the permission combinations currently in use across a space's grantees (returns a taskId)

2. Poll GET /tasks/{taskId} until COMPLETED

3. GET /combinations — list the combinations that aren't yet mapped to an RBAC role

4. POST /role-assignments — bulk assign roles so existing users and groups retain equivalent access under the new model

5. POST /access-removals — bulk remove the legacy permission grants that have been superseded by role assignments

6. Poll GET /tasks/{taskId} for the assignment / removal tasks until COMPLETED

These endpoints are experimental. We're validating the API contract against real-world migration workloads and plan to stabilize it once we've confirmed the shape holds across a range of tenant configurations.

Available now in all Confluence Cloud editions in roles transition mode. Please raise issues on the Atlassian Developer Community if you find anything.

A new Rovo-powered AI chat widget is now available for all logged-in users on https://developer.atlassian.com. Located in the bottom right corner of developer documentation pages, this assistant can answer questions, surface relevant docs, and help you build on the platform faster.

Key features include:

• Contextual answers: The chat understands the context of your question and provides relevant answers rather than generic search results.

• Developer-focused knowledge: Trained on Atlassian developer documentation, the assistant understands Forge, REST APIs, Marketplace, and platform concepts.

• Natural language understanding: Ask questions in plain language; no need to know exact documentation titles or keywords.

• Follow-up questions: Continue a conversation naturally with follow-up questions to drill deeper into a topic.

• Source transparency: The widget displays the specific documentation and support sources used to generate each answer.

• Conversation history: You can access and review your previous interactions for up to 28 days.

• Independent operation: The assistant works independently of your product licenses and organization-level AI settings.

For more details on how the assistant handles data and what sources it uses, see the Atlassian developer AI chat documentation.

What’s changing:
The Confluence Cloud REST API v2 endpoints for listing page and blogpost versions now enforce a maximum limit of 50 results when the body-format query parameter is included. Requests without a body-format parameter are unaffected.

Affected endpoints:

• GET /wiki/api/v2/pages/{id}/versions

• GET /wiki/api/v2/blogposts/{id}/versions

Previously, requests with body-format could return up to 250 results. If the requested limit exceeded the maximum, the API returned a 400 Bad Request error.

With this change, if the requested limit exceeds 50 when body-format is specified, the response will be capped at 50 results and return 200 OK.

What you need to do:

If your integration relies on receiving more than 50 versions in a single request with a specific body format, you must update your logic to handle pagination. Use the cursor provided in the _links.next field of the response to fetch subsequent pages of results.

As recently announced in Raising the bar on Marketplace cloud app security: together we are updating the Marketplace Security Bug Fix Policy to shorten vulnerability remediation timelines for Marketplace cloud apps. These changes ensure a higher security standard across our ecosystem.

What’s changing
The remediation Service Level Objectives (SLOs) for Marketplace cloud apps are being shortened. The timelines for Data Center apps remain unchanged.

Updated Cloud App SLOs (Enforceable September 1, 2026):

• Critical: 10 days

• High: 4 weeks

• Medium: 12 weeks

• Low: 25 weeks

Data Center App SLOs (Unchanged):

• Critical: 12 weeks

• High: 12 weeks

• Medium: 12 weeks

• Low: 25 weeks

Additionally, we have published the Marketplace Security Enforcement Policy, a consolidated source of truth for marketplace security compliance expectations, including vulnerability management, OAuth compliance, partner verification, bug bounty participation, and incident response.

What you need to do

• Review the new timelines: Ensure your internal processes are updated to meet the new cloud app SLOs by September 1, 2026.

• Check your tickets: We have corrected an issue where some AMS Data Center tickets incorrectly showed cloud remediation dates. If you believe a ticket still has an incorrect date, please raise an ECOHELP ticket.

• Watch the policy page: The Marketplace Security Enforcement Policy is a living document, we recommend "watching" the page for future updates.

We've introduced the Tile component for Forge UI Kit apps, now available in Preview. The Tile component is a rounded square container for displaying assets like emojis, or objects in a consistent, styled way.

The component supports various sizes (from 16px to 48px), customizable background colors using design tokens, optional borders, and adjustable internal padding for different asset types including third-party logos.

For implementation details and examples, see the Tile component documentation.

A new RFC is ready for review at RFC-136

A new optional boolean parameter, generateAppEvents has been introduced to the following Jira Cloud REST API endpoints

• POST /rest/api/2/app/field/value - Update custom fields

• PUT /rest/api/2/app/field/{fieldIdOrKey}/value - Update custom field value

What it does: When set to false, this parameter suppresses the generation of app events triggered by the update. Specifically, it prevents issue updated events from being dispatched to:

• Forge app event listeners

• Connect app event listeners

• OAuth 2.0 app webhooks

• Admin-configured webhooks (registered via the Jira admin UI)

Default behavior: When omitted or set to true, all app events are generated as usual.

The boolean usages of the autoFocus prop have now been removed from @atlaskit/modal-dialog. The previously default value of true, which automatically moves focus to the first interactive element within the modal, is now the default with no option to set it to false. This is to improve accessibility and follow the WCAG guidelines for focus within a modal dialog.

Boolean usages of autoFocus can be removed by running the included codemod.