apiPulse.app

Atlassian

Atlassian developer platform changelog updates

Atlassian API Changelog Monitoring

Atlassian ecosystem changes can affect marketplace apps, Jira and Confluence integrations, and admin workflows used across enterprise teams. This Atlassian API Changelog Monitoring page helps you review updates in a structured way before they ripple into production usage.

Better Atlassian API Changelog Monitoring helps marketplace and internal-tool teams understand changes to platform behavior, APIs, and policies before customers raise issues. It supports a cleaner release process by turning changelog review into a routine instead of a scramble.

The benefit of Atlassian API Changelog Monitoring is simple: your team gets a repeatable way to watch changes, evaluate risk, and act before small upstream updates turn into customer-facing bugs. Atlassian developer platform changelog updates

Atlassian API down?

Atlassian API down? Soon we will add direct API status monitoring alongside Atlassian API Changelog Monitoring. For now, go to the official API status page on the Atlassian website. In the future, we plan to detect downtime signals even before the public status page is updated.

Recent changes

Showing the last 10 changes from this feed.

10-15-2026

[Fixed] Update to Confluence Content Restrictions V1 API behavior for read and update operations

Rollout: progressive rollout by tenant IN PROGRESS What's changing We are updating the behavior of the Confluence Cloud REST API V1 content restrictions endpoints to ensure consistency between view and edit access. Previously, it was possible for a principal (user or group) to hold an update (Can edit) restriction without holding the corresponding read (Can view) restriction on content that had view restrictions applied.After this change:All principals will hold either only the read restriction (Can view) or both the read and update restrictions (Can edit).If a principal holds both read and update restrictions, any API request to remove only the read restriction will result in a rejection.To move content into an "edit restricted" state for these principals, you must request the removal of all read restrictions.What you need to do If your application manages content restrictions via the Confluence Cloud REST API V1, review your implementation to ensure:When granting update access, you also include the read restriction for that principal.Your logic for removing restrictions accounts for the fact that read access is now a prerequisite for update access.

Source
10-15-2026

[Added] (Experimental) New REST APIs for managing and applying space policies in Jira Cloud

What's changing We've introduced new experimental REST APIs for managing space policies in Jira Cloud. Space policies allow site administrators to govern the creation and usage of fields and statuses in team-managed spaces, helping to prevent configuration sprawl and maintain instance health.The following experimental endpoints are now available:Viewing policiesGET /rest/api/3/policies — Get all policiesGET /rest/api/3/policies/project/{projectIdOrKey} — Get project policy stateGET /rest/api/3/policies/project/{projectIdOrKey}/rules — Get project policy rulesApplying policies to projectsPOST /rest/api/3/policies/{policyId}/apply — Apply a policy to projectsPOST /rest/api/3/policies/{policyId}/remove — Remove a policy from projectsPUT /rest/api/3/policies/project/{projectIdOrKey}/policies — Set the policies applied to a projectPOST /rest/api/3/policies/project/{projectIdOrKey}/validate — Validate policy application to a projectWhat you need to doReview the Jira Cloud space policy API documentation to understand the available methods and data structures.Note that these APIs are currently experimental and may change without notice.If you are building integrations that create fields or statuses, ensure you handle potential blocks when a space policy is active.

Source
10-15-2026

[Announcement] Teamwork Graph API is now in Preview

The Teamwork Graph Consumption API is now moving into Preview, providing relationship-first querying across Atlassian Cloud objects and connected third-party tools.What's changingThe Teamwork Graph API lets you query connected context across Jira work items, Confluence content, Loom videos and meetings, external development artifacts, Goals, and Teams using a unified GraphQL endpoint.

Source
10-14-2026

[Added] New V2 Confluence Permissions REST APIs

What's changing We are introducing new Confluence Cloud REST API v2 endpoints to manage content permissions and restriction states. These endpoints provide a consistent way to handle permissions across multiple content types, including pages, blog posts, databases, whiteboards, and folders.The new endpoints are:GET /wiki/api/v2/{content-type}/{id}/restriction-state: Retrieves the current restriction state of the content.PUT /wiki/api/v2/{content-type}/{id}/restriction-state: Updates the restriction state (for example, to make content restricted or open).GET /wiki/api/v2/{content-type}/{id}/permissions: Lists the specific permissions (read and update) applied to the content.POST /wiki/api/v2/{content-type}/{id}/permissions: Adds new permissions for a user or group.PUT /wiki/api/v2/{content-type}/{id}/permissions: Updates existing permissions.DELETE /wiki/api/v2/{content-type}/{id}/permissions: Removes permissions. What you need to do If you are building new integrations or migrating from the V1 content restrictions API, we recommend using these new v2 endpoints.

Source
10-14-2026

[Added] Speed up app migrations with the new Confluence macro index feature

A feature to speed up app migrations that require transforming confluence macros has been added. This implements RFC-142.See the documentation here.

Source
10-13-2026

[Announcement] MCP apps are now available on Atlassian MCP V2

We’re excited to announce that the below tools now support showing rich UI cards on Atlassian MCP V2. Jira : getJiraIssue, editJiraIssue, createJiraIssue, transitionJiraIssue, and searchJiraIssuesUsingJqlConfluence : searchConfluenceNOTE: We are doing a steady rollout across all customers, and if you do not see these by 23 Oct 2026 , please reach out to support.

Source
10-13-2026

[Deprecation Notice] Git Credential Manager (GCM) upgrade required for continued OAuth 2.0 Git authentication

What's changingOn 30 Nov 2026 Git requests authenticated using OAuth2.0 via the Git Credential Manager (GCM) will be blocked for versions prior to 3.0.0. This is caused by the lack of support for rotating OAuth refresh tokens, which have recently begun being enforced for Bitbucket’s OAuth 2.0 implementation. See:  https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3052 . Atlassian contributed changes to the open source project to include support for the rotating refresh token model, which was bundled in the v3.0.0 release ( https://github.com/git-ecosystem/git-credential-manager/releases/tag/v3.0.1 ) What you need to doIfAction/s Required?You are NOT using Git Credential ManagerNo action is requiredYou ARE using Git Credential Manager configured with personal access tokensNo action is requiredYou ARE using Git Credential Manager configured with OAuth2.0You must upgrade Git Credential Manager to a version 3.0.0 or higher by 30 Nov 2026 if you wish to continue to authenticate Git using this mechanism. Simply upgrading the version should ensure seamless authentication.Attached fileNote: Impacted users will see a message after each git push operation prior to upgrade.

Source
10-12-2026

[Added] Dynamic modules, customer-managed egress, and customer-managed remotes are now generally available in Forge

Dynamic modules, customer-managed egress, and customer-managed remotes are now generally available on the Forge platform.Dynamic modules let a Forge app register and manage modules at runtime through the Dynamic Modules API, rather than declaring them statically in the manifest. These modules are available across Jira, Confluence, and Jira Service Management.Customer-managed egress lets Atlassian administrators configure the external domains a Forge app may send data to.Customer-managed remotes let Atlassian administrators configure the remote backends a Forge app may communicate with.For more information, see Dynamic modules and Customer-managed egress and remotes.

Source
10-09-2026

[Added] Forge display conditions now support arrays under logical operators for Jira and JSM modules

What's changing Forge display conditions for Jira and Jira Service Management (JSM) modules now support arrays under the and, or, and not logical operators. Previously, manifest keys had to be unique at each level, which made it difficult to repeat the same condition type or group multiple logical expressions. With this update, you can use an array of condition objects to define complex visibility logic more easily.For example, you can now structure your manifest to group conditions or repeat the same condition type:displayConditions: or: - and: - entityPropertyExists: { entity: user, propertyKey: a } - entityPropertyExists: { entity: user, propertyKey: b } - and: - entityPropertyExists: { entity: user, propertyKey: c } - entityPropertyExists: { entity: user, propertyKey: d } What you need to do No action is required for existing apps, as the previous syntax remains supported. If you want to simplify complex logic or repeat conditions in your Jira or JSM modules, you can update your manifest to use the new array-based syntax.For more details and examples, see the Forge display conditions documentation.

Source
10-08-2026

[Announcement] Direct JQL validation for custom JQL functions returns to Search REST APIs

We are reintroducing direct JQL query validation to the Search REST API (/rest/api/3/search/jql) specifically for queries that use custom JQL functions. Previously, when the new Search REST API was introduced, JQL validation was moved exclusively to the parse endpoint (/rest/api/3/jql/parse). Based on developer feedback, we are bringing this capability back to the search endpoint for custom JQL functions. If a JQL query containing custom JQL functions is invalid, malformed, or references unsupported functions or arguments, the search API will now return an immediate HTTP 400 Bad Request with detailed error messages. This change applies exclusively to custom JQL functions; native JQL queries and other general usages of the search endpoint remain unaffected and will continue to follow existing validation behaviors.What you need to doSimplify your integration: If your app uses custom JQL functions, you no longer need to make a separate pre-flight call to the JQL parse API (/rest/api/3/jql/parse) to validate these queries before searching.Update error handling: Ensure your search API integrations are prepared to handle HTTP 400 Bad Request responses and can inspect the returned error messages when executing queries that include custom JQL functions.Review documentation: For more information on constructing queries, refer to the Jira Search REST API documentation.

Source