How to Let People Request Access to a Private Page

You shared a private page with three people at a client, and the fourth person who needs it forwards the link to themselves and gets a locked door. On SnapHost that person can request access to a private page from the door itself: they confirm their email, press one button, and you get a request you can approve or turn down without leaving the page's sharing settings.

This post walks through what the viewer sees, what you see, what approving does, and the places where the flow is less automatic than you might hope. It assumes the page is restricted to named people, which is the default on Pro. On a page open to anyone with the link there is nothing to request.

Why request access to a private page at all

A private page is only as useful as the list of people who can open it, and that list is wrong more often than you would think. You name the people on the kickoff call. Then the client's finance lead needs the numbers, the agency brings in a contractor, and someone's assistant opens the link on their behalf. None of them are on the list, and each one has to email you, wait, and try again.

The usual way out is to loosen the page: make it public, or put a password on it and send the password around. Both work, and both mean you no longer know who is reading. The alternative is to leave the page restricted and give the person at the door a way to ask. That is what an access request is. The page stays private, you stay the one who decides, and the asking happens where the person already is instead of in your inbox.

What the person at the door sees

Someone who opens a restricted page is asked for their email. The screen says it plainly: type your email, get a code, no account and no password. The code goes to any address they type, so this step tells them nothing about whether they are on your list. That is deliberate. The page would otherwise be a way to find out who you have shared with.

They enter the six-digit code. If their email is on the list, the page opens. If it is not, the same screen comes back with a different heading: they do not have access yet, their email is not on this page's access list, and they can ask the owner or sign out and try another email. Under that is a Request access button and, if they want it, a short note for the owner.

Once they press the button, the screen tells them the owner has been asked to give that email access and that they will hear back by email. From their side, that is the whole thing. There is no account to create and nothing to come back and check.

What you see

You and any admin of the workspace get a notification in the dashboard, and an email if you have email notifications on. The email names the person and the page and has one button, which takes you to the page's sharing settings. It does not approve anything by itself. The decision is made in the dashboard, so a click in an inbox does not add anyone to a list on its own.

On the page's Share card the requests sit at the top: one person asked, or three people asked, each with the email they verified and the note they wrote if they wrote one. Each request has Approve and Deny beside it.

If you manage sites from your AI instead of the dashboard, the same queue is there. Ask it what is waiting on the page and it lists the pending requests; tell it to approve one and the person is added to the list. The docs for your AI's connection list the three calls involved.

What approving actually does

Approving a request adds the requester's email to the page's access list and marks the request decided, in one step. There is no state where the request says approved but the person is still locked out, or where they can get in but the request is still waiting. The person then gets an email saying their request was approved, with a button that opens the page at the address you share.

Their email is now an ordinary entry on the list. Nothing about it says it arrived through a request rather than through you typing it. You remove it the same way you remove anyone, and the post on revoking access to a shared link covers what that does and does not undo.

Denying marks the request decided and leaves the list untouched. The person gets an email saying the request was not approved and suggesting they contact whoever shared the page. A decided request cannot be decided again. If the same person asks again later, a new request opens.

If the same person presses the button twice before you have looked, you see one request, not two. A repeat from an email that is already waiting updates that request rather than adding another.

Who can approve

Deciding a request takes a workspace owner or admin who can also edit the page. A member who can edit the page but is not an admin cannot clear the queue, and an admin who has no access to a colleague's private page cannot see who asked to view it. The second check is the same one that guards the page's access log. The decision is recorded in the workspace audit log with the email it admitted.

What the access log records

Separately from the request queue, the page's access log records the attempt. When someone presses Request access, a requested event is written with their email, and because that email was not on the list, a denied event follows it. The log keeps both even after you decide, so a month later you can still see that a particular address tried the link and was turned away. That is often the first sign that a link has travelled further than you sent it, and what an access log for a shared page tells you goes through how to read those events.

Where the flow stops short

A few honest limits, because they shape how you should use this.

It is a Pro feature. Access requests are part of the sharing controls that come with Pro, along with lists longer than three people, passwords and link expiry. On the Free plan a page can be private to up to three named people, and you add them by hand. The door still shows a Request access button on a Free page, but pressing it files nothing and notifies nobody, so if you are on Free, tell people to email you instead. The pricing page has the current plan lines.

The person hears back by email only. They have no account and no inbox on SnapHost, so the decision reaches them as an email, sent on a best-effort basis after you decide. If that email is lost, nothing else tells them. If someone says they asked and heard nothing, check the Share card, and if the request is already approved, send them the link again. It will open.

It does not pre-fill a list for you. Each request is one email. If a whole company needs the page, do not approve them one at a time. Add the company's domain to the list, like acme.com, and anyone with an address there gets in without asking.

There are limits on asking. A single sender can only make a handful of requests to one page in a ten-minute window, and a page holds at most a hundred pending requests before new ones from new addresses are quietly dropped. Neither matters for a client deliverable. Both exist so the button cannot be used to flood your inbox.

Requests, passwords and one-time links

An access request is one of three ways to let in someone who is not on the list, and it is worth knowing when to pick the others.

A view password on a restricted page is a second way in: anyone holding the password opens the page without being on the list. It is the right tool for a room full of people you cannot name in advance and the wrong tool for a page where you want to know who read it, which is the whole argument in website allowlists vs passwords.

A one-time link lets one person open a restricted page once, with no sign in and no password. It has to be opened within seven days and works for a single sitting of about an hour, and changing the page's general access or its password cancels it. It is the right tool for a reviewer who needs one look today and should not be on the list tomorrow.

An access request is the right tool when you want the person on the list, you want them to prove the email first, and you want to be the one who says yes. The person asks once, you decide once, and from then on they open the page the way everyone else on the list does, for as long as their verified email is remembered, which is fourteen days from their last visit inside a ceiling of ninety.

In practice most client pages end up using the list plus requests. You name the people you know about at the start. The ones you did not know about ask, and you approve them from the same card you set the page up on. The full set of controls is in the sharing docs.