Control who can open the hosted page
Four modes — public, secret link, shared password, or named accounts — plus one toggle that decides whether any of them apply.
Browse topics
What it is
By default, anyone with your hosted page link can open it and chat. Access control lets you put a gate in front of it.
There are four modes:
| Mode | Visitor must | Good for |
|---|---|---|
| Public | Nothing | Anything you would put on a business card |
| Secret link | Have a link containing a key | A quick, low-friction private share |
| Password | Know one shared password | A small group, short term |
| Accounts | Sign in with their own credentials | Named people, revocable one at a time |
Above the four sits a Require sign-in toggle. With it off, every mode behaves exactly like Public — so a page that is not working as a gate is usually a page whose toggle was never switched on.
None of this applies to the website widget. That is protected differently — see Hosted page vs website widget.
When you would use it
Gate the page when the URL should not be world-readable: an internal staff FAQ, a client preview before launch, a members-only resource, a chatbot trained on material you do not want indexed or shared.
Leave it public when the whole point is reach — a support link in your email signature, a QR code on a poster, a bio link.
Where to find it
Open Dashboard → Chatbots → your chatbot → Integrations → Messaging → Direct link, then find the Who can access section.
Choosing between them
Public. The default. Anyone with the URL can chat. Simple, and correct for most customer-facing chatbots.
Secret link. Agentency generates a long random key and gives you a URL containing it. Anyone holding that URL is let in automatically — the page submits the key for them, so there is no form to fill in. Lowest friction of the three gates, and the weakest: the key travels in the link, so a forwarded email hands over access. Good for a client preview, not for anything sensitive. The key is shown to you exactly once, when it is generated. Copy it then; it cannot be displayed again, only replaced.
Password. One password, shared by everyone. A visitor is asked for it before they can chat. Better than a secret link because the password is not embedded in the URL, but it is still collective — you cannot remove one person without changing it for all of them.
Accounts. Each person gets their own identifier and password, up to 100 per chatbot. The only mode where you can see who has access and revoke one individual. See Credentialed accounts on the hosted page.
The question that usually decides it: when one person leaves, what do you want to happen? If the answer is "just that person loses access", you need Accounts. If "everyone re-learns a new password" is acceptable, a shared password is fine.
Steps
- Open Dashboard → Chatbots → your chatbot → Integrations → Messaging → Direct link.
- Find Who can access.
- Turn on Require sign-in. Leaving it off makes every mode behave as Public.
- Choose the mode.
- Secret link: generate the key and copy the URL immediately. It is shown once.
- Password: set the shared password. Leaving the field blank keeps the current one — it does not clear it.
- Accounts: add at least one enabled account before you rely on the page.
- Save.
- Test in a private browsing window. This is the only test that means anything: your dashboard session is not the gate, and it will let you straight through.
What you will see
The Who can access section lists the four modes with a one-line hint under each. Selecting one reveals its own controls: the secret generator, the password field, or the accounts list.
Secret mode shows the share URL with the key in it, plus a Regenerate link action. Password mode shows a single field with the placeholder "Leave blank to keep the current password".
The drawer warns you when a mode is selected but unusable — a password mode with no password set, or an accounts mode with no enabled accounts, will tell you plainly that nobody can open the link until you finish.
Revoking access
Two facts to hold together.
Changing the secret or the password immediately invalidates every pass already issued. Everybody is turned out and has to re-enter the new one. This is your emergency eviction: if a link leaked, regenerate.
Switching modes also clears the previous mode's secret. Move from Secret to Password and the old key is gone, not parked. Switching back later generates a new key rather than resurrecting the old one — which is the safe behaviour, because a key you shared two months ago should not silently start working again.
For per-person revocation without disturbing anyone else, only Accounts can do it: disable or delete that one row.
How long a visitor stays unlocked
Once someone passes the gate, their browser holds a pass for roughly 12 hours. They are not re-prompted mid-conversation, or every time they reopen the link during a working day.
This is why a change you make can look like it did nothing: your own browser, and theirs, may still hold a valid pass from before. Test in a fresh private window, and remember that changing the secret or password is what actually clears everyone.
Repeated failed attempts at the gate are rate-limited per visitor and per chatbot, so a password cannot be guessed at speed.
Limits and plan notes
- Access control is managed by the chatbot owner, and is set per chatbot. It is not a workspace-wide policy.
- A page with no mode chosen, or with Require sign-in off, is public. Public is the default and it is not an error state.
- The whole feature can be switched off at the installation level, in which case every hosted page is public regardless of its stored setting. If your gate seems to be ignored everywhere, that is worth asking about.
- The accounts list holds up to 100 people. That is a safety ceiling on the list, not a billing seat — adding someone there does not cost you a workspace seat.
- Passwords and secrets are stored only in scrambled form and cannot be read back. Support cannot recover a secret you did not copy; you regenerate it.
- Gating the hosted page does not gate the website widget, and does not affect messaging channels.
Common problems
I set a password and the old link still works.
Either Require sign-in is off, or the browser you tested with still holds a valid pass. Test in a private window. To evict everyone properly, set a new password or regenerate the secret.
I lost the secret link.
It is shown once and cannot be retrieved. Regenerate it — which also invalidates the old one, so anyone using it will need the new URL.
My iframe stopped working after I turned on the secret.
The key lives in the URL's query string. When you add other parameters, keep the existing key rather than replacing the query string wholesale. See Iframe embed and direct link.
Nobody can open the page at all.
A gate with nothing behind it: password mode with no password, or accounts mode with no enabled account. The drawer warns about both.
Visitors get a 404 rather than a gate.
That is not access control. A 404 means the chatbot is draft or paused. See The hosted page is 404.
The widget on my website is still open to everyone.
Expected. Access control covers the hosted page only. The widget is protected by its token and allowed domains — see Allow the widget on your domains.
Common questions
Which mode should I choose?
Ask what should happen when one person leaves. If only that person should lose access, you need Accounts. If everyone re-learning a password is fine, use Password.
I set a gate and the link still opens. Why?
Either Require sign-in is off — which makes every mode behave as Public — or your browser still holds a valid pass. Test in a private window.
How do I evict everyone at once?
Change the shared password or regenerate the secret. That invalidates every pass already issued, and everyone has to enter the new one.
I lost the secret link. Can I see it again?
No. It is shown exactly once. Regenerate it — which also invalidates the old one, so anyone still using it will need the new URL.
Does this protect my website widget too?
No. The widget is protected by its token and allowed-domain list. Gating the hosted page leaves the widget exactly as it was.
Was this article helpful?
Related articles
Credentialed accounts on the hosted page
Give up to 100 named people their own username, email, or phone plus a password — and remove one without disturbing the rest.
Share a hosted chatbot link
The fastest way to put a chatbot in front of people, and the one public surface available on every plan including Free.
Hosted page vs website widget
Same knowledge, same credits, same conversations — different identification, different access control, different plans.
Allow the widget on your domains
Only listed hostnames may load your widget. An empty list means "not configured", so live sites are blocked.
Ready to try it on your own content?
Create a free workspace, add a document, and ask the questions your team is tired of answering.