Confluence: Disable Request Access for Spaces and Pages

To disable (turn off) the Request access button in Confluence Cloud, go to Confluence administration > Settings > Permissions > Access requests and switch off the toggle on either tab (Space access requests or Content access requests). Confluence asks you to confirm with Stop allowing. Before you click it, know that switching off content requests deletes every pending page request on your site. On our test site the one we'd queued up was already gone at our first API check, 4 seconds after the confirmation closed.

People have been asking for this switch for a long time. Possible to turn off the "Request Access" feature? has 2,022 views on the Community, and the answer there was that no such option existed. The page-level ticket, CONFCLOUD-33703, was opened in May 2014, and Atlassian closed it as Fixed on 1 October 2026. When I read it on 29 October it had 145 votes and 125 watchers. Its space-level sibling, CONFCLOUD-78577 (148 votes), followed on 8 October. Atlassian's staff announcement had 70 views that day.

So we tried it on our own site on 28 October 2026. A second test account, Elzi, asked for access to a locked space and a restricted page. Then we switched both toggles off, wrote a message that sends people to a Jira Service Management request type, and looked at the result from Elzi's seat. Mihai (my colleague at LeanZero) did the clicking from his admin account, which is why his name shows up in one screenshot. Afterwards everything went back to how it was.

Note

Prerequisites: Confluence Cloud and a Confluence administrator account (Atlassian's doc says "Confluence administrators" and names no other role; we used an account that is both site admin and Confluence admin). For the JSM part you'll need a Jira Service Management service space (a Jira space, nothing to do with Confluence spaces) where you're a Jira or space admin, plus an API token, curl and jq if you want to create the request type over REST. Atlassian doesn't say which plans get the setting. Ours is Confluence Premium, and it's the only plan we tested.

Before you switch it off: it's one setting for the whole site

There's no per-space version. Atlassian's doc says turning off space access requests "prevents users from requesting access to all spaces in your Confluence site", and we didn't find anything in a space's own settings either. If you only want to stop requests for one sensitive space, this won't do it.

Plan for the pending requests. Page requests (Atlassian calls them content access requests, and they cover whiteboards and blog posts as well as pages) wait for the owner as flags and notifications until someone approves or denies them. Switch the content toggle off and they're deleted, for the whole site, and nothing on the page tells the people who asked. The Access requests page only has the toggles and the message, and we didn't see pending requests listed anywhere in Confluence administration. Whoever got each request (the page owner first, then the creator, the last editor or a space admin, per Atlassian's doc) sees it in the notification or under the page's Share button, where the doc says deferred requests wait. So give your page owners a day's notice.

Find Access requests under Confluence administration > Permissions

[[steps]]

1. Open Confluence administration: click the gear icon in Confluence's top bar and pick Confluence administration. You'll get the admin sidebar, with a Jump to setting... search box at the top.
2. Expand Permissions, not Security: Security is its own group just above it, and the doc said Security until late September (a Wayback copy from 21 September 2026 still has it). Both the live doc and our menu say Permissions.
3. Click Access requests: it sits between Space management and Guest access. Its address ends in /wiki/admin/access-requests, so you can also bookmark it.
4. Check the two tabs: Space access requests and Content access requests. Each has a toggle card, and under it a preview of the screen people get when they hit something locked. You should see the page titled Access requests with both tabs and, if nobody has changed it yet, the toggle on, as in the screenshot below.

While a toggle is on, the page only previews the lock screen. You get the message options after you switch it off.

Turn off Confluence space access requests

Stay on the Space access requests tab and click the toggle. A dialog asks "Stop allowing space access requests?" and warns that "All pending requests will be removed, and people will no longer be able to ask for space access on this site." Click Stop allowing and the toggle is saved straight away, with no separate Save. Then pick the message: Use default message keeps Atlassian's standard lock screen, and Use custom message gives you an editor (more on writing one in the JSM section).

The dialog warns about pending space requests too, while the doc only mentions pending requests for content. We couldn't test that part. On our site, space requests aren't stored as pending items at all. Elzi's request sent a "Request sent" flag, but no in-app notification arrived on the admin side (we couldn't read the admin's mailbox), and Confluence's own API told us "Stateful space access requests are disabled for this tenant." Atlassian's doc says space requests go by email to 20% of the space's eligible admins, rounded up, up to five people. So on a site like ours there's probably nothing to remove, and on yours there might be.

Elzi's page request was still pending after we switched space requests off, so the toggles work separately and you can do one at a time.

Disable Request access to a page: pending content requests are removed

Before switching anything off, we had Elzi ask for a page. She opened the restricted page and got "This content is locked for now". When she clicked Request access, the button turned into Access requested.

On the admin side, a notification came in: "Elzi requested access to a page". Its link opened the page with a Requests dialog.

Open the Content access requests tab and click the toggle. This time the dialog asks "Stop allowing content access requests?", with the same warning: "All pending requests will be removed, and people will no longer be able to ask for access to content on this site." Click Stop allowing, pick a message and click Save (the toggle saves itself, but the message needs Save). To check it worked, go back to an old request notification. You should see the page open with no Requests dialog.

We checked through Confluence's API before and after. Before, Elzi's request was listed as PENDING. Our first check, 4 seconds after the Stop allowing dialog closed, found the list of pending requests empty. The bell notification ("Elzi requested access to a page") was still there, but it led nowhere, so nobody could approve it any more.

Switching the toggle back on doesn't bring anything back either. It asks no question, it just turns on. When Elzi reloaded the page afterwards she got a fresh Request access button, where before she'd had "Your request is in the works". Her request was deleted, and nothing on the page said so (we didn't check her email). Atlassian's doc covers this with a single sentence: "Turning off content access requests automatically removes all pending requests for your site."

Send Confluence access requests to Jira Service Management with a custom message

Atlassian's doc says the switch is "useful when you manage access through central ticketing systems like Jira Service Management to keep a consistent audit trail of all access requests." You need a request type on your service desk, a link to it, and a message that carries the link.

You can create the request type in your service space in Jira (Space settings > Request management > Request types > Create request type), or over REST. We used REST. Set three variables first, your site address, your Atlassian account email and an API token:

export SITE=https://your-site.atlassian.net EMAIL=[e-mail] API_TOKEN=your-token

Creating a request type is still marked experimental and needs the opt-in header. The two lookups work without it, but sending it does no harm, so we put it on every call. This lists your service desks and their ids:

curl -s -u "$EMAIL:$API_TOKEN" -H 'X-ExperimentalApi: opt-in' "$SITE/rest/servicedeskapi/servicedesk" | jq -c '.values[] | {id, projectKey, projectName}'

On our site it printed:

{"id":"2","projectKey":"DEMO","projectName":"Demo service project"}
{"id":"142","projectKey":"HSD","projectName":"Harbourline Support Desk"}
{"id":"1","projectKey":"JT","projectName":"JSM Test"}

We used JSM Test, id 1. A new request type also needs a work type id, and the easiest place to find one is an existing request type on the same desk:

curl -s -u "$EMAIL:$API_TOKEN" -H 'X-ExperimentalApi: opt-in' "$SITE/rest/servicedeskapi/servicedesk/1/requesttype" | jq -c '.values[] | {name, issueTypeId}'

{"name":"Ask a question","issueTypeId":"10019"}
{"name":"Emailed request","issueTypeId":"10020"}
{"name":"Submit a request or incident","issueTypeId":"10018"}

We reused 10019, the Ask a question work type. Then the request type itself:

curl -s -u "$EMAIL:$API_TOKEN" -X POST "$SITE/rest/servicedeskapi/servicedesk/1/requesttype" -H 'Content-Type: application/json' -H 'X-ExperimentalApi: opt-in' -d '{"name":"Confluence access","description":"Ask for access to a Confluence space or page","helpText":"Tell us which space or page you need and why.","issueTypeId":"10019"}' | jq '{id, name, portalId, groupIds}'

This is what it printed on our site:

{
  "id": "581",
  "name": "Confluence access",
  "portalId": "1",
  "groupIds": []
}

Look at the empty groupIds. A request type made over REST isn't in any portal group, so it doesn't show on your portal's home page. Its direct address works anyway. On our site the first one we made (id 579) opened at /servicedesk/customer/portal/1/create/579, and yours will have its own two ids. If you create the request type in the UI, open it on the portal and copy the address from your browser. Add it to a portal group in the UI if you want people to find it from the help center too.

[[steps]]

1. Switch the toggle off on the tab you're changing: the message choice only shows up while the toggle is off.
2. Choose Use custom message: an editor labelled Message (required) appears, with buttons for bold and links.
3. Type the sentence, then add the link with the link button or Cmd+K: fill in Paste a link and Text to display. Pasting a bare URL works too, but people then see the whole URL. Selecting text first and pressing Cmd+K didn't wrap it for us, it inserted the URL after the selection.
4. Click Save: the message is saved for that tab only. Space and content each have their own, so repeat it on the other tab.
5. Open a locked page from a test account: you should see your message and link where the Request access button was.

If you want a starting point, this is the text we'd paste on the Content tab. Make Request Confluence access the link, and on the Space tab say space instead of page (it's 174 characters, well under the 500 limit):

Access to this page is handled by the IT service desk. Request Confluence access and tell us which page you need and why. You may be asked to log in to the help center first.

Check what a requester sees after Request access is disabled

Elzi reloaded the restricted page once content requests were off and our message was saved. The heading lost its "for now", the Request access button is gone, and the link is clickable.

If you keep Use default message instead, people still lose the button. With the toggle off, the settings preview of the default space screen said "This space is locked for now" and "You don't have permission to access this space.", with only Go home under it (we didn't load it from Elzi's account). Nothing tells people where to ask, so we'd always write a custom one.

On the locked space it looked the same: "This space is locked", our space message with its link, and Go home. Clicking the link opens it in the same tab.

When Elzi clicked it, the help center's login page opened ("Enter your email to log in or sign up") where we expected the form. Our test account's saved session didn't carry over to the portal, so we couldn't confirm what someone who's already logged in sees. From Mihai's admin account the link opened the form directly. Your users might get a login step first, so it's worth one sentence in your message.

Where it stops: no per-space or per-page Request access toggle

A Community thread with 1,030 views, Override, Replace or Remove "Request Access" for a particular space, asks for exactly the thing this setting doesn't do. Its asker, on Confluence Server, wanted requests for one space sent to a Jira ticket. Every Atlassian source I read describes the new controls as site-wide, and the space-level ideas are still open: CONFCLOUD-79172, choosing which space admins get space requests, had 75 votes and was Gathering Interest when I read it on 29 October.

A few more limits from our run. It's Cloud only (the Data Center ticket, CONFSERVER-33703, was closed as Won't Fix in 2014). We only tested Premium, and Atlassian's announcement was marked ROLLING OUT in the Cloud changes for 21 to 28 September 2026, so your site might not have the page yet. And the setting leaves permissions alone: people who couldn't see a page still can't. If your permissions are messy after a migration, that's a separate job, and Mihai wrote up how we check Confluence space permissions after a migration. If you have Atlassian Guard, the data security policy controls are the other half of locking content down.

On the JSM side, the request type is just a ticket. Somebody still has to grant the access in Confluence. If you want an approval step on those tickets, the approval setup in our JSM change management tutorial works the same way for an access request type.

If it didn't work

You can't find Access requests. It's under Permissions in Confluence administration. Security is the group just above it. Try the Jump to setting... box, or open /wiki/admin/access-requests directly. If it isn't there, the rollout may not have reached your site yet.

There's no Use custom message option. It only appears while that tab's toggle is off.

Your message only shows on pages and not on spaces (or the other way round). Each tab has its own message. Set it on both.

The link shows as a long URL. Use the link button or Cmd+K and fill in Text to display.

The REST call answers "This API is experimental." Add the header -H 'X-ExperimentalApi: opt-in'. The full message is "You must set the header 'X-ExperimentalApi: opt-in' to opt into using this API."

People say the link sends them to a login page. That's the help center asking them to sign in. Our test account hit it too.

Someone's old request vanished. That's the content toggle doing what its dialog says. Switching it back on won't restore it, so ask them to request again or raise a ticket.

What you have now

[[takeaways]]

• Request access switched off for spaces, pages or both, from Confluence administration > Settings > Permissions > Access requests.
• A custom message on each tab that sends people to a Confluence access request type on your service desk, so access requests leave a ticket trail.
• A clear picture of the cost: pending page requests are deleted the moment you confirm, the approver's notifications stop working, and turning it back on doesn't restore them.
• Not covered: switching it off for a single space or page, and Data Center. We also only saw it on Premium.

Did you turn it off for the whole site, or are you holding out for a per-space switch? And if your space requests do show up as pending items (ours didn't), I'd love to hear what the dialog removed for you. Tell me in the comments or mail gabriela at leanzero.net :)

---

Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.