Client sign-up and portal isolation
Open self-serve sign-up on your own domain, choose the plan new clients land on, and understand the host binding that keeps your portal and ours separate.
Once your domain is live, you can let visitors create their own client workspace on it — no invite, no provisioning step on your side. Sign-up is off by default, and the auth on your domain is bound to your organisation whether you open it or not.
Invite-only until you open it
A live custom domain serves invite-only auth: the login page shows no "Sign up" link, and /signup redirects to /login unless the visitor arrives carrying a live invite. That is the default, and it is the right setting for a portal you provision by hand.
Allow clients to sign up
Settings → Client sign-up — the organisation owner or a primary-workspace admin, active reseller plan, domain live. The card is inert until the domain is live — a pending or failing domain would send verification links nobody can open.
Two controls:
| Control | Effect |
|---|---|
| Allow clients to sign up | Shows "Sign up" on your domain and opens /signup |
| Default plan for new clients | The plan the new client workspace lands on — free, starter or pro |
With the toggle on, /signup on your domain creates the visitor's own account plus a client workspace under your organisation that they own. You are not added to that workspace as a member — their Team page shows no one else from day one — and you take no seat there; you reach it through read-only client-view access like any other client. You get a New client signed up notification, and the row shows a Client-owned badge (the same badge a completed handover invite shows).
Choosing the default plan. free carries a flat quota and works the moment they sign in. A paid platform plan is credit-metered from your pool — no credits are allocated at sign-up, so you must allocate credits or assign one of your client plans afterwards, or their bot stays unfunded. No subscription is created at sign-up either way.
Seats
Every self-serve sign-up consumes one of your client seats, exactly like a workspace you provision by hand.
- Out of seats — or when your org's pooled knowledge sources can't fund the default plan — the sign-up page says "Sign-ups are currently closed" and the API refuses with
USAGE_LIMIT_REACHED. It is the same seat + source-pool gate that hand-provisioning runs. - The visitor must verify their email — branded, and linked back to your domain — before their first sign-in.
- A sign-up that is never verified is deleted after 7 days, which frees the seat again. Nothing to clean up by hand.
An invite behaves differently from a sign-up: a live invite to a workspace already inside your organisation bypasses both the sign-up toggle and the seat cap, because joining an existing workspace costs no seat. An invite for a workspace outside your organisation never opens a closed portal.
Who can sign in where
Auth is host-bound at the API, not just hidden in the interface. Three rules follow from that:
On your domain, only your people. Your staff, your clients, and anyone they invited can sign in, reset a password, or resend a verification link. Everyone else gets the same "invalid email or password" response as a wrong password — nothing about accounts elsewhere leaks, and no email leaves your domain that isn't branded for you.
Your clients cannot sign in on ours. An account that exists only as your client is refused on app.evoriqa.com, and the login page tells them where they belong: "Your account is at your-domain. Sign in there." Someone who also has their own Evoriqa workspace sees only that one on the platform host, and only your client workspace on your domain — the two never mix.
An outside email cannot sign up on your domain. If the address already belongs to an account outside your organisation, sign-up is refused and the address receives a notice branded for you — "This email can't be used here" — with no link to any other portal.
When a self-serve client leaves
A self-serve client owns their workspace, so they can delete their own account. When they do, the workspace is handed back to you: you become its owner, their data stays with you, and their personal account is purged the usual way. The client relationship ends without the workspace, its conversations, or its knowledge base going with it.
Where to go next
- Branding and domain — getting the domain live, which is the prerequisite for all of this.
- Client workspaces — provisioning by hand, seats, and per-client limits.
- Billing your clients — putting a self-serve client onto one of your paid plans.
Last updated