Credentialed accounts on the hosted page

What it is

Accounts is one of the four ways to control who can open your hosted chatbot page, and the only one where each visitor has their own credentials.

You create a small list of named accounts — up to 100 per chatbot. Each has an identifier (a username, an email address, or a phone number), a password, and an optional label so you can remember who it belongs to. A visitor opening the page is asked to sign in with one before they can chat.

The other three modes are covered in Control who can open the hosted page. Come here when you have decided that one shared password is not enough.

When you would use it

Choose Accounts over a shared password when you need to know who, or when you need to remove one person:

• A staff chatbot. Everyone gets their own login, and when someone leaves you delete their account rather than changing a password for the whole company.
• Client previews. Each client gets their own credentials and cannot see that anyone else has access.
• A paid or members-only chatbot. Access is per person and revocable per person.
• Anywhere a shared password would leak. A password given to twenty people is a password on the internet.

Stay with a shared password when access is genuinely collective and short-lived — a workshop, a one-week campaign. Creating twenty accounts for a two-hour event is not worth it.

Where to find it

Open Dashboard → Chatbots → your chatbot → Integrations → Messaging → Direct link, then find Who can access.

Before you start

• Decide the identifier type before you create the list. Uniqueness is enforced per type, so sam as a username and sam as a phone are two different rows. Mixing types across a list you will maintain for a year is a small mess you can avoid now.
• Have a way to send credentials. You will be creating passwords and giving them to people. Do that over something private, not a group chat.
• Create at least one account before you save the mode, or the page locks everyone out — see the warning below.

Steps

1. Open Dashboard → Chatbots → your chatbot → Integrations → Messaging → Direct link.
2. Under Who can access, turn on Require sign-in and choose Accounts. The hint confirms it: "Visitors must sign in with an account you create."
3. In the Accounts section, use Add account.
4. Choose the Type — Username, Email, or Phone.
5. Enter the identifier the person will type.
6. Enter a password. Minimum four characters, but pick something real — see below.
7. Optionally add a Label, such as "Reception desk" or "Acme — Sara". This is for you; the visitor never sees it.
8. Save the account. Repeat for each person.
9. Save the access settings.
10. Test it in a private browsing window. Your dashboard view is not the gate, and it will happily show you the chat whatever the setting says.
11. Send each person their URL, identifier, and password.

The lockout warning

If you select Accounts and save with no enabled account in the list, nobody can open the page, including you as a visitor. The drawer warns you: "Add at least one enabled account — until you do, no one can open this link."

Take the warning seriously. Create the first account before you save the mode, or immediately afterwards. Nothing is broken and no data is lost, but your public link is a locked door until you add someone.

What the visitor sees

Not your dashboard, and not a chat. They get a small sign-in card headed "Sign in to continue", marked as protected, with a line underneath asking them to sign in with their account to open the chatbot.

It has two fields — Username, email, or phone and Password — and an Unlock button. The card carries your chatbot's own colours, avatar, and name, so it does not look like a generic interruption.

Get it wrong and the message is "Incorrect credentials. Please try again." — deliberately vague. It does not say whether the identifier exists, because that would let someone probe your list to discover who has access.

Once they unlock, they chat normally. They are not signing in to Agentency and they do not have an Agentency account; they have unlocked one chatbot page.

How long a sign-in lasts

After a successful unlock, the visitor's browser holds a pass for that chatbot for about 12 hours. They will not be re-prompted every time they open the link during a working day, and they will be asked again the next morning.

The pass is per browser. The same person on their phone and their laptop signs in on each.

Managing the list

Adding is the flow above. There is no bulk import; you add people one at a time. That is a mild inconvenience at ten people and a reason to reconsider the approach at eighty.

Disabling switches an account off without deleting it. Their credentials stop working immediately and the row stays, so you can switch it back on later. This is the right move for someone on extended leave, or when you are not yet sure whether the access should end permanently.

Deleting removes the account. The dialog asks to confirm — "Remove access for …?". Use this for people who have genuinely left.

Changing a password is an edit on the existing account, so a person who has forgotten theirs keeps the same identifier. There is no self-service password reset for visitors; you set the new password and tell them.

Renaming an identifier is also an edit, and the new value has to be unique for its type on this chatbot.

Each row shows when that account last signed in, which is the quickest way to spot credentials nobody uses. An account that has never been used a month after you created it is usually one you can delete.

Limits and plan notes

• Up to 100 accounts per chatbot. This is a safety ceiling on the list, not a billing limit — these are visitors, not workspace seats, so adding people here costs you nothing. See Seats and billing for teams for the thing that is a seat.
• One hundred is deliberately modest. This feature is for a small trusted group, not a user directory. If you are approaching the ceiling, you probably want your own site's login in front of an iframe embed instead.
• Passwords must be at least four characters. That is the technical floor, not advice — treat these like real passwords, because they protect real content.
• Identifiers are case-insensitive at sign-in, so Sara and sara are the same person.
• The chatbot owner manages this list. It is not a workspace-wide directory and it is not shared with your other chatbots — each chatbot has its own.
• Passwords are stored only in a scrambled form that cannot be read back. Neither you nor support can look up someone's password; you can only set a new one.
• Repeated failed attempts on the sign-in card are rate-limited per visitor, so the list cannot be brute-forced.
• None of this applies to the website widget, which is protected by its token and allowed-domain list instead. See Hosted page vs website widget.

Common problems

Nobody can get in, including me.

Either there are no accounts in the list, or every account is disabled. Add or enable one.

Someone says their password does not work.

Check the identifier type matches what they are typing — an account created as Email needs the email address, not a username. Then check the account is enabled. Then set a new password and send it to them.

I deleted someone and they are still chatting.

Their 12-hour pass is still valid in that browser. It expires on its own. To evict everyone immediately, switch the mode away and back, or change the shared secret if you were using one — that invalidates every issued pass.

I want to know which account said what in a conversation.

The account list records last sign-in time per account, which tells you who has been active. Conversation-level attribution to a named account is not something the dashboard shows.

Can visitors change their own passwords?

No. There is no self-service reset for these accounts. You set passwords and you reset them.

I need more than 100 people.

The ceiling is fixed. At that scale, put the chatbot behind your own site's login and embed it in an iframe on an authenticated page — see Iframe embed and direct link.

I set this up and the link still opens without asking.

Check Require sign-in is actually on — a mode selected while the toggle is off behaves exactly like Public. Then re-test in a private window; your own browser may hold a valid pass from earlier.