Accounts
Turn the app into a SaaS of your own: your customers sign up, each one gets a bot and a workspace of their own, they bring their colleagues in by link and hand out access themselves — and no customer ever learns that another one exists.
Your customers sign up to you
This is the module that turns the app into a product you sell. Every account that signs up gets a bot and a workspace of its own, sealed off from every other customer on the deployment.
A bot with every sign-up
Somebody fills in the form and walks out with a bot of their own, ready to use. Your server creates it with your credentials, which never reach a browser.
More bots, whenever they want
An account is not stuck with the one it started on — it can add, rename and delete its own bots whenever it needs another. The topbar switches between them.
Colleagues join by link
An admin makes an invite link, and whoever opens it joins that workspace with the role the link names rather than getting one of their own. It can be pinned to a single address, and revoked.
Access handed out one bot at a time
Inside a workspace, a colleague reaches the bots they were given and nothing else. Outside it there is nothing to reach at all — another customer’s workspace does not exist as far as this account is concerned.
Each customer runs their own team
They invite colleagues, decide who is an admin, hand out access and pass ownership on — without asking you for any of it. It is their workspace to run.
One customer never sees another
A signed-in customer who somehow learns another customer’s id still cannot open anything of theirs. Every request is checked against what that session may reach, before it leaves your server.
On your own Supabase project
The accounts, the passwords and the workspace tables live in a project you own, with your data and your keys. The wizard can create it for you from an access token it uses once and keeps in memory only.
Roles the database enforces
Owner, admin and member are checked by the functions that do the work, not only by the menu that offers them — a workspace’s own tables cannot be reached directly at all. At most one owner is a unique index, so it is a fact rather than a convention.
Every screen sign-in needs
Signing in, signing up, accepting an invite, forgetting a password and resetting one — and the dead ends too: a link that expired, an account that belongs to nobody here. Eight screens, and the only one inside the app’s own chrome is Team.
A sign-up that never half-works
A new customer either lands in a working app with their agent ready, or nothing is created at all. Nobody is left staring at an account that says “setting up” for ever, and nobody has to clean one up.
Sign up, invite, hand out access
Accounts is opt-in: the wizard never installs it with --yes, because it needs a Supabase project it cannot invent. Name it on the command line — the module id is auth — and everything below is already wired.
Somebody signs up
The form is the one every SaaS has. Behind it your server claims them a workspace, reserves a row for a bot, and creates that bot in Chatfuel with your master token — in that order, so a failure at any point leaves nothing half-made and no orphan in your account.
They invite their colleagues
An admin creates a link on the Team page, with a role on it, optionally pinned to one address, and optionally carrying the bots the recipient should arrive able to open. Accepting joins the inviter’s workspace instead of opening a second one, so a team is one workspace and not five.
Everyone reaches what they were given
Inside their workspace your customer decides who reaches which bot. Outside it nothing is reachable: every request is checked against that one workspace before it leaves your server, so a customer cannot see, name or open anything belonging to another.
Three roles inside one customer’s workspace
These are the roles your customer hands out to their own colleagues, and they never reach past the workspace they are in. Owner and admin come with the whole workspace by role, so there is no grant list beside them that could be taken away by accident.
| Name | What it means | Reaches every bot |
|---|---|---|
| Owner | At most one. Cannot be removed, cannot be demoted, and cannot leave without handing ownership to somebody else first. | |
| Admin | Manages members, invites and bots — creating, renaming, deleting and handing out access. Cannot touch the owner row. | |
| Member | Uses the bots they were granted, and the Team page shows them an empty state. | Only granted |
The screens it ships
Eight of them, written and styled with the rest of the app. Seven replace the interface entirely; Team is the one rendered inside it, and it opens from the avatar menu rather than the nav rail.
| Sign in | Email and password, then back to wherever the person was headed when they were stopped. |
| Sign up | Creates the account and its first bot in one go, and stays on screen to say which half failed when one of them does. |
| Invite | Previews the link before anyone types a password into it: the workspace, the role, who sent it — and why a dead link is dead, rather than a 404. |
| Forgot password | Always answers the same way, so the form never tells a stranger whether an address has an account here. |
| Reset password | Takes the link from the email or the one an admin issued, and works in whatever browser it is opened in. |
| Auth callback | Where Supabase comes back to, including the refused and expired links that never reach the client library at all. |
| No access | Signed in, and not a member here. Ask an admin for an invite, or sign out and come back as somebody else. |
| Team | Members and invites in one table, the workspace’s bots in another, and leaving or transferring ownership at the bottom. |
What it holds
The shape of a workspace, and the ceilings the module and the database agree on.
| Workspaces one account owns | 1 |
| Owners in a workspace | 1 |
| Bots an account may create | Whatever the plan allows |
| An invite link, by default | 7 days |
| An invite link, at most | 30 days |
| Expiries the dialog offers | 1, 7 or 30 days |
| An invite token | 24 random bytes |
| Bot name | 80 characters |
| Your name | 60 characters |
| Password | 8 characters |
| An access answer is reused for | 30 seconds |
| A half-made bot is swept after | 10 minutes |
FAQs
On your own Supabase project, as email and password — you own its data and its keys, and nothing about sign-in runs on somebody else’s service. The wizard can create the project for you from a personal access token, which it uses once, keeps in memory only and never writes anywhere.