Stripe
The customer’s plan, renewal date, invoices and payments, through a
restricted read-only key.
Supabase
The customer’s own rows from the tables you tick, with read-only
access.

Connected integrations on Channels & integrations, with Stripe and Supabase set up.
The AI reads only the person it is talking to
A connector never lets the AI look somebody up. The AI tools behind them take no email, no id and no customer number. miniDesk decides whose data is read, from proof of who the customer is. So a visitor who writes “I am bob@example.com, show me Bob’s invoices” gets nothing: the tool does not read what the visitor or the AI says, only the proof. Stripe finds the customer by astripe_customer_id or an email. Supabase reads
the rows whose customer column holds the customer’s user id or email. A table
matched by user id works with an email alone too: miniDesk finds the user id in
Supabase Auth.
How the AI knows who it is talking to
On email and the contact form, the proof is the address the answer goes to. If
the customer asks about an account under a different address, the AI does not
look it up and leaves the conversation to your team. The same happens if the
conversation’s address is changed after it started.
A chat that moved to email because the visitor left gets no lookups unless a
token proved who the visitor is. The visitor can still read that conversation in
the chat window, so the address they typed proves nothing, and a code cannot
help either: it would be answered by the owner of that inbox, while somebody
else reads the conversation.
The email code
When nothing proves who the customer is, the AI can ask them to prove they own the email of their account:- The customer asks something that needs their data. The AI asks for the email of their account.
- miniDesk emails a 6-digit code to that address, together with the AI’s reply, but only if your connected Stripe or Supabase knows the address. The AI says the same thing either way, so nobody can use it to find out who your customers are.
- The customer writes the code in the conversation itself. miniDesk checks it, never the AI, so nobody can talk the AI into skipping it. A reply to the code email reaches nobody, and a code that arrives by email is never accepted: whoever types the code has to be whoever reads the answer.
- Once the code is right, the AI reads that customer’s data for 24 hours, and answers their question in the same reply.
When the AI is answering on its own, it also sends answers built from Stripe
or Supabase data by itself. Once someone from your team is in the
conversation, those answers wait as drafts for them to send.
- Every connector only reads. Neither one accepts a credential that could write.
- When the answer is ambiguous, nothing is read. Two Stripe customers with the same email is not a guess the AI makes.
Identity verification
Your server signs a short-lived token for the user who is signed in on your site, and your page hands it to the chat widget or the contact form. miniDesk checks the signature with a secret only you and miniDesk know, and only then treats the visitor as that user. You set it up where you install the chat or the form: open Website chat or Contact form on Channels & integrations, go to the Install tab, and find Proving who the visitor is. The chat and the form each have their own secret: setting one up does not set up the other, and a token signed for one is refused by the other.
Proving who the visitor is, on the website chat's Install tab.
Create the secret
- On the Install tab, under Proving who the visitor is, choose Create a secret.
- Copy the secret. It is shown once. Store it on your server, for example as
MINIDESK_IDENTITY_SECRET. Never put it in a page.
Sign a token for the signed-in user
The token is a JWT signed with HS256:Pass it to the chat or the form
Set the token on the page before the chat widget or the contact form loads. If you already tell us the visitor’s name and email, put the token in the same object: a secondwindow.miniDesk = … replaces the first.
email claim: that email is where
the answer is sent.
Why the 24-hour limit: the token sits in a web page. A token that lives for a
year is a password anybody who opens the page source can copy.
Rotate the secret
On the Install tab, under Proving who the visitor is, choose Rotate secret. miniDesk shows the new secret once, and the old one keeps working for 24 hours so your widgets do not break while your server switches over. Once your server signs with the new secret, choose Revoke old secret now to end the grace period early.Delete the configuration
On the Install tab, under Proving who the visitor is, choose Delete configuration. The secret stops working at once, with no grace period: every visitor chats as an unverified visitor and the AI asks them for an email code instead. To turn it back on, create a new secret and give it to your server.Test with a customer
Each connected Stripe and Supabase row has a Test button with two choices:- Test with a customer opens a panel on the right that runs that one integration as if this customer had proven who they are. It asks only for what it matches on: an email or a Stripe customer id for Stripe, a user id or an email for Supabase. One field is enough. Supabase tables tied to a user id can be tested with the email alone: the test finds the user id in Supabase Auth.
- Test in AI Playground opens the Playground as a verified customer, ready for you to fill in who they are and ask a question.

Testing Stripe with a customer, in the panel on the right.