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-16-2026

[Announcement] Global Apps EAP

EARLY ACCESS: Forge Global Apps We are ready to kick off the Forge Global Apps Early Access Program (EAP). Forge Global Apps are installed in the platform and can optionally link to one or more Atlassian apps.What's changingInstallation into unit instead of an Atlassian app workspaceApps can work across sites in a unitNo required Atlassian app link What you need to do Sign up for the EAP: submit a request  https://ecosystem.atlassian.net/servicedesk/customer/portal/1040/create/18611  and we will get in touch with instructions soon

Source
10-16-2026

[Announcement] Atlassian cloud will start using new IP address ranges as we expand our cloud infrastructure

What's changing From January 1, 2027, Atlassian cloud will add new IP address ranges as we expand our cloud infrastructure.The new ranges are in addition to our existing ones.The new ranges are:New range: 131.162.88.0/21Requests to Atlassian (browsers and your clients calling Atlassian APIs): 131.162.88.0/23Requests from Atlassian (webhooks, Connect lifecycle calls, and other requests from Atlassian to your app): 131.162.90.0/23What you need to do If your app, remote backend, or integration allowlists Atlassian IP addresses, you must add these ranges before January 1, 2027, to avoid service interruptions.These ranges are already included in our official IP range list (viewer tool). If you automate your allowlist updates from this file, no further action is required. For more details, see our documentation on IP addresses and domains for Atlassian cloud apps.

Source
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