Since around yesterday (2026-07-07) we observed that the restrictions API stopped working (e.g. https://developer.atlassian.com/cloud/confluence/rest/v1/api-group-content-restrictions/#api-wiki-rest-api-content-id-restriction-put ).
Anybody observing this also in their instances? We already opened an ECOHELP ticket, but no response yet.
If you are getting a 403 bounce from the restrictions API it may be the same one we’ve seen sporadically over the last month, in some customer sites and our test sites.
We believe the cause is some unadvertised security change that Atlassian is rolling out that changed enforcement of restrictions or broke existing security permissions on spaces. Note that it appears only affect some spaces on some sites.
The workaround that we have found is to force grant the “Restrictions” permission to our app user or the confluence-users group for the affected spaces.
Are you programmatically modifying the permissions for the app user to include “Restrictions”? If so, which API are you using for this? Or do you (or the end user) have to do it manually?
Our workaround is the manual checkbox. 
Hey all - apologies for this disruption.
What happened: A change intended for customers using Confluence role-based access was rolled out to all Confluence Cloud sites. This caused some space admins to lose the ability to manage content restrictions.
Background: Up until recently, holding the Admin space permission allowed users to manage content restrictions for all content in the space. These users essentially inherited the Restrictions > Add/Delete space permission, whether they explicitly held it or not.
With the introduction of role-based access in Confluence (SAC ref, recent blog post), we removed silent permission inheritance. The result is that users need to hold two space permissions explicitly – Manage all content in space and Manage access to individual content – to manage restrictions for all content in the space and use the related Restricted content management experience in space settings.
What we’re doing: We’re rolling out a fix now. The new enforcement will only apply to sites in ROLES mode. Sites still in PRE_ROLES or ROLES_TRANSITION mode will continue to work as before — space admins will retain their inherited ability to manage content restrictions without needing additional explicit permissions.
How to check a site’s mode: Can use Get space role mode API here
We apologize for the disruption and will follow up with updated documentation clarifying this behavior.
Hi,
Thank you for the response.
As this is related to the roles rollout, is there any guidance for developers and about how apps should handle the Add/Delete restrictions permission?
Further to @marc’s comment, can Atlassian provide guidance on exactly how roles are intended to interact with app users? Up until now, my understanding is that app users have been effectively included in certain hidden groups (atlassian-addons, or sometimes hidden users within confluence-users), which granted access to spaces unless an admin manually configured them otherwise.
I checked a recent RBAC-enabled tenant and found that there is a new “Apps” page under Space Access, but this page only seems to include permissions for Confluence Questions and nothing else.
How is this intended to work going forward with RBAC? Can apps assume that they will have access to all permissions in all spaces by default? Can admins manually override this? If so, how? Are app permissions directly visible to admins through the Confluence UI, or is Confluence still relying on hidden groups and/or hidden users within public groups? And if admins can withdraw permissions, what do you suggest as the best way for apps to detect this?
The goal of these questions is to allow vendors to understand the permission environment in which their apps are operating, and to be able to design apps that warn admins directly if something needs to be changed.
I am also hoping to understand the presence of potential footguns: for example, admins sometimes managed to inadvertently nuke app access by deleting a common user group that Confluence was using under the covers (with hidden apps users within the group), even though the group was not otherwise needed by the customer. Effectively, vendors would appreciate knowing how apps permissions will be represented, displayed and controlled in the RBAC environment.
Thanks!
Scott
Hey Marc & Scott - appreciate the questions & our intention is to make sure this rollout goes smoothly for all.
Responding to general guidance
For context, App Installations that do not happen in RBAC mode (pre-roles aka “legacy”):
-
For Connect apps that hold WRITE scope → will be granted Space > Admin but not Restrictions > Add / Delete
- (this is the primary case being discussed here, and how installs have historically worked)
-
For Connect apps that do not hold WRITE scope → no direct space permissions are granted
-
For Forge apps that hold write || delete scopes → same as 1st Connect case
-
For Forge apps that do not hold write || delete scopes → same as 2nd Connect case
For the cases where no direct space permissions are granted, Apps gain Space access via the default user groups, as they have before.
Moving forward - for App Installations that happen in an RBAC mode (transition or roles aka “roles only”) - the above still holds, with the following adjustments:
-
Instead of a set of permissions that include Space > Admin, the Admin role is granted
-
Admin role holds all space permissions - including Manage all content in space & Manage access to individual content.
- (Manage access to individual content == Restrictions > Add / Delete)
Let’s now discuss Apps installed in “Legacy” mode and the transition, eventually, to “Roles Only” mode (along with all other permission assignments).
Before “Roles Only” mode, sites will enter “Roles Transition”. This is the GA rollout that is happening now, and thousands of sites opted into this early over the last year during our open Beta. In this mode, the implied inheritance of Manage access to individual content from Manage all content in space will continue to hold.
Next - During the move from Roles Transition → Roles Only, product admins will need to move all assigned access (App Users and the default groups included) over to access via Roles. In the vast majority of App user cases, the Admin role will be chosen (and is our in-product recommendation), for which Manage access to individual content is held.
Once sites move from “Roles Transition” to “Roles Only”, this implied inheritance will be gone, but most Apps will now hold Manage access to individual content explicitly with the Admin role.
If there are a minimum set of permissions an app needs to function correctly in a use-case, ideally marketplace apps will call that out to product admins, ideally by recommending a default role that meets their needs.
Around how roles interact with app users & the new “Apps” page
The Space access > Apps screen is meant for configuration of space-level permissions that impact custom content declared by Apps. It isn’t actually new, but was moved in the experience. It exists for legacy tenants as well, and is broadly unchanged between RBAC and pre-RBAC sites.
For example - if User X or Group Y have permission to add the app-declared “Questions” content type within that Space.
Permissions for Apps themselves continue to be directly assignable, and inherited from the default group, and live under the unified Users screen, where they are granted space permissions akin to other User Types.
This view can also be filtered to Apps only via the User type dropdown.
To your series of questions near end of post Scott -
Apps with “write+” scopes should generally assume they will have all space permissions by default (detail above). Permissions assigned to apps will continue to be directly visible and modifiable via the Confluence UI. As in the past, product admins and space-level ‘admins’ will be able to override this, either while transitioning to “Roles Only” mode, or explicitly on a per-space basis.
If Admins withdraw these permissions, we would suggest handling the 403 however makes the most sense to your app. Also - we have now updated our documentation with additional clarification (ref), see: Manage all content in space.
Please let us know any additional questions, here to support!
Our “legacy” apps had the permission to add/remove restrictions, and many of our customers depend on it for already a long time.
This seems to contradict the above statement.
Confirmed that our experience is what @marc relayed. Our connect and connect on forge apps were able to adjust content restrictions with only the default Admin checkbox attached to the app user. Then over the last few months random customers lost this ability.
Hopefully Atlassian can unbreak this and restore the restrictions permission is available to admins/admin role after this rather awkward transition.
I might suggest a public BUG and dev Feed associated with this defect so at least we can point our confused customers at it as why the apps are spontaneously unable to edit restrictions in their spaces when they were not informed that any security changes were being made by Atlassian in their sites.