Where your data lives
Which machine holds what, how credentials are stored and why there is no reveal button, incoming addresses as credentials, and what we can see.
Your operator runs on a server provisioned for you and nobody else. This page is the plain version of what sits where, who can reach it, and what we can see.
On your server
| What | Why it is there |
|---|---|
| Conversations, and its memory of the people in them | It is the working memory. Every reply depends on it, so it sits next to the thing doing the work. |
| Call transcripts and anything sent by webhook | It arrives, it is written down, and it is read where it landed. |
| Your knowledge base | Everything from Teach. |
| The credentials you connected | So it can use them without a round trip to us on every call. |
| Its own record of what it did | Which is what the counts on Skills are read from. |
On ours
| What | Why it is there |
|---|---|
| Your portal login and who may use it | The list has to be somewhere you can still reach if your box is down. |
| An encrypted copy of each credential | This is what lets us deliver it to your server, and redeliver it after a rebuild without asking you to paste everything again. |
| Billing | Ordinary subscription records. |
Note what is not on that second list: your customer conversations, your transcripts and your operator's memory. Those exist on your machine and are not copied to ours.
Credentials
A credential you paste is encrypted before it is stored and is never shown again on any screen, to you or to us.
You paste it once
Into Connections.
It is encrypted and delivered to your server
So your operator can use it directly.
It is never displayed again
If you need to know whether one still works, reconnect it and let the check answer. There is no reveal button, deliberately.
Disconnecting revokes it both places
Here, and on your server.
Scope credentials down in the vendor wherever the vendor allows it. A restricted Stripe key and a scoped Cloudflare token do exactly the same work here with a fraction of the exposure if anything ever goes wrong.
Incoming addresses are credentials too
The addresses on your Connections page that your own systems post to have no second secret: the address is the whole of it. Anyone holding one can hand work to your operator.
Keep them inside the tool that is sending, not in a shared document or a ticket. If one leaks, rotate it and the old address dies immediately. See sending things to your operator.
What we can see
We can reach your server to support it, and we do when something is broken or when you ask. We do not read your customer conversations as a matter of course.
Nothing on your server is pooled with another client's, and no other client's operator can reach yours. That is a property of the architecture rather than a policy: they are different machines.
Yes. Ask on Requests. It is your data and it is on your server.
There is a hold period before anything is removed, and a full backup is taken and verified before any deletion happens. Nothing is deleted the day a payment fails.
Your operator learns from your own material on your own machine. Your data is not pooled into anything shared across clients.
Our engineers, for support. Access is through our own managed path rather than shared logins, and it is used to fix things rather than to browse.
What happens to your data if things go wrong
| Event | What happens to your data |
|---|---|
| Your box needs rebuilding | It is restored, and the credentials we hold encrypted are redelivered so you do not paste everything again. |
| A payment fails | Nothing, on the day. There is a grace period and we contact you inside it. |
| The account is stopped | The box is stopped and held. Stopped is not deleted: the volume and everything on it are intact. |
| The account ends | A full backup is taken and verified before anything is removed. A restore has to be something we can actually perform, so it is tested rather than assumed. |
The order matters and is deliberate: a verified backup comes before any deletion, not after. A backup nobody has restored from is a hope rather than a backup.
Who can reach the box
| Who | How | Why |
|---|---|---|
| Your operator | It runs there | It is the machine doing the work |
| You, through the portal | Signed in | Everything you see is read from it |
| Our engineers | Through our managed path, not shared logins | Support |
| Another client's operator | Not at all | Different machine. This is architecture rather than policy |
Practical things worth doing
Scope every credential down in the vendor
A restricted key does the same work here with far less exposure if anything ever goes wrong.
Rotate an incoming address if it has been pasted anywhere shared
The address is the entire secret, so a screenshot in a group chat is a leak.
Tell us the day somebody leaves
Portal access is a conversation with an operator that knows your customers.
Ask for an export whenever you want one
It is your data. There is no retention argument to have.
Was this page helpful?