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.

08-28-2026

[Added] Bulk fetch issues now supports up to 1000 issues per request

The Bulk fetch issues API (POST /rest/api/3/issue/bulkfetch) now supports a maximum of 1000 issues in a single request, up from the previous limit of 100. This higher limit is available for requests optimized for efficient processing.  https://community.atlassian.com/forums/Jira-Cloud-Admins-articles/1-000-Issues-One-Call-Bulk-Fetch-Gets-a-10-Boost/ba-p/3281867  What's changing To qualify for the 1000-issue limit, your request must meet the following criteria:Explicit field selection: You must explicitly name at least one field to include. Wildcards like *all or *navigable, and requests containing only exclusions (e.g., -description), are not eligible.Field count: No more than 100 fields can be explicitly included.Single-value fields only: Included fields must not return multiple values (e.g., comment, worklog, or attachment are excluded).Restricted expands: The expand parameter must not include changelog, editmeta, operations, renderedFields, transitions, or versionedRepresentations.What you need to do No action is required if you wish to continue using the existing 100-issue limit. To take advantage of the 1000-issue capacity:Update your request payload to explicitly list the specific fields you need.Remove any multi-value fields or restricted expand parameters.Increase your batch size up to 1000 issueIdsOrKeys.If you require multi-valued data or changelogs for a large set of issues, we recommend splitting the work: use one 1000-issue call for "cheap" fields and separate, narrower calls for complex data. For changelogs, use the Bulk fetch changelogs endpoint to avoid the 40-item cap imposed by expand=changelog.For more details, see the Bulk fetch issues reference documentation.

Source
08-28-2026

[Added] New raise issue on support site API

We’ve added a new API to allow callers to raise an existing issue on a CSM support site.

Source
08-27-2026

[Announcement] Web trigger lifecycle APIs now available for Forge Container Services

You can now manage web trigger URLs programmatically from within your Forge Container Services environment. These new REST API endpoints provide parity with the @forge/api package and the Forge CLI, allowing your container-based apps to create, list, and delete web trigger URLs.What's changing We’ve added the following HTTP endpoints to the Forge Container Services REST API:POST /forge/webtrigger/url: Create a new web trigger URL or retrieve an existing one.GET /forge/webtrigger/urls: Retrieve all web trigger URLs associated with the app.DELETE /forge/webtrigger/url: Delete a specific web trigger URL. These endpoints enable containerized apps to handle their own web trigger lifecycle dynamically without relying on external CLI commands.What you need to do If your container-based app requires dynamic web trigger management, you can start using these endpoints immediately. Refer to the Forge Container Services REST API documentation for detailed request and response schemas.

Source
08-26-2026

[Announcement] Removal of site limit for the Forge Export app logs API

What's changing We have removed the limitation on the number of sites for which you can retrieve logs using the Export app logs API. Previously, the API was limited to returning logs for a maximum of 3,500 sites. This restriction has been lifted, allowing you to export logs across all sites where your app is installed and log sharing is enabled.What you need to do No action is required to benefit from this change. If you were previously limited by the 3,500-site threshold when polling for logs across your entire install base, you will now receive logs for all eligible sites automatically.For more information on how to use the API, refer to the Export app logs documentation.

Source
08-26-2026

[Added] Global Statuses are now available in team-managed workflows

The Global Statuses Beta for team-managed spaces is now live. As previously announced, this feature allows global (site-wide) statuses to be added to team-managed workflows.To try it, enable the feature via Jira Labs. Once enabled:Workflow create and update APIs support global statuses in team-managed workflows.Space templates will create workflows with global statuses by default.Global statuses may appear in workflow read responses for team-managed spaces.

Source
08-25-2026

[Deprecation Notice] App macros will move to a single category as element browser categories are modernized

In 6 months on 25 Feb 2027, app macros will only appear in one category in the modal element browser, and the categories ([string]) property will be fully replaced by a new category (string) property for Forge app macros. Furthermore, we’re updating both the slash menu element browser and modal element browser to improve discoverability of our shared offerings, expected to begin rollout on 06 Oct 2026. These changes impact all apps using macros and require action. Read More details below for more information on what’s changing, action required, and timelines.

Source
08-25-2026

[Announcement] Reverting maintenance period correction for refund rows

We’re reverting the change announced in CHANGE-3388 due to technical challenges with the data.The maintenance period shown on refund (credit note) rows in Marketplace reporting will return to the previous behavior while we address these challenges.What’s changingThe correction that expanded refund maintenance periods to reflect the full term across all constituent invoice lines is being reverted and old behaviour is being restored prior to CHANGE-3388What’s not changingRefund amounts are unchanged. As it only updated the reported period dates; no monetary values are affected.The majority of refund rows, approximately 86%, were already displaying the correct period and will still be unimpacted.What you need to knowReview your reporting. If you use maintenance period dates from Marketplace reports to calculate period-based metrics, such as annualized revenue or daily run-rate, you may see changes for reverted refund rows.No action is required if you only use refund amounts in your reporting, because those values remain unchanged.We’ll provide a further update when the correction is ready to be reintroduced.

Source
08-25-2026

[Added] Rovo Agent Connector — EAP to Preview

The Rovo Agent Connector is now officially in Preview. You can now deploy apps using this module to production and staging environments, enabling Marketplace listing.What's changingA2A v1.0 is now required — v0.3 is no longer supported. Apps still on v0.3 will be rejected at deployment. See the migration guide for full details.System user mentionability — adding rovo:agentConnector to your app makes the system user non-mentionable; the agent connector user takes its place. The CLI (v13.3+) warns and prompts for approval at deploy time.What you need to doAdd version: "1.0" to protocols.agent2Agent in your manifest.Update your JSON-RPC implementation to the A2A v1.0 protocol — see the migration guide.Update to Forge CLI v13.3+ (npm install -g @forge/cli@latest).For full integration details, see  https://developer.atlassian.com/platform/forge/remote-agents-in-jira/  and the  https://developer.atlassian.com/platform/forge/manifest-reference/modules/rovo-agent-connector/ .

Source
08-24-2026

[Deprecation Notice] The diff/diffstat APIs will no longer support the `?merge=true` parameter

This deprecation was originally announced in 2022, and we are proceeding with the removal of the merge parameter now. More information including about alternative solutions for merge conflict retrieval can be found in our community post about this change. This capability will be removed as of September 4th, 2026.

Source
08-21-2026

[Announcement] Marketplace partner listing APIs now restrict emergency support contact details to authorized callers

Deprecation Notice We’ve updated Marketplace partner listing API responses so that emergency support contact details are returned only to callers who are authorised to manage partner details. Unauthorised or anonymous callers will no longer receive the emergency contact field field in listing support contact data. This change aligns listing access with the current Marketplace roles and permissions model and is an important security measure. Integrations consuming listing support contact data should not assume that the ‘emergency contact' field is always present and should handle missing values accordingly.

Source