Everything you have to do — read it before you pay
Your automation runs on a server you own, under your own accounts. That is the arrangement rather than an upgrade, and it means there are a few things only you can do. This is all of them, written out before you pay rather than after, along with the parts we would rather you heard from us than worked out later.
Who does what
Nothing on your side of this table can be handed to us, and nothing on ours needs you.
| The thing | Whose it is |
|---|---|
| The server it runs on, and the card that pays for it | Yours |
| The login you create when you first open it | Yours. You are the owner and the only account |
| Your text and email sending accounts | Yours. You enter them; we never receive them |
| Building it, shipping fixes, watching it | Ours |
| Turning it off | Either of us, at any moment |
The part that is not fifteen minutes
If your service sends text messages, US carriers require your business to be registered before they will deliver any of them. It is days to weeks, it is in your legal name against your own tax details, and nobody can speed it up afterwards. Start it the day you buy: it sets your go-live date and nothing else on this page does.
This is the main reason we lead with the email version of the review service. Email works the day the card clears. Texting waits on a regulator, and pretending otherwise would just move the disappointment two weeks later.
Claim your account
You open the setup screen and enter a name, an email and a password. Whatever you enter becomes the owner account — the only account, with full control. Use an email you will still have in two years and put the password in your password manager.
We cannot recover it for you, and there is no reset email, because there is no service of ours behind it to send one.
Store your encryption key
You get a long string of characters that encrypts every credential you are about to enter. It is generated on your own server. Put it in your password manager next to the login and leave it there.
If the server is lost and you do not have this key, every credential on it is unrecoverable. A backup does not help you, because the backup is encrypted with the same key. This is the one genuinely irreversible thing in the whole process, and it is the one thing a machine cannot do for you: generating it is easy, deciding to still have it in two years is not.
Add your own accounts
You need your text provider's API key, and if your service sends email, your mail server details. You enter them yourself, into your own system, where they are encrypted the moment you save them and shown afterwards as dots.
Nobody reads them back out again, including you. There is no screen we could read them off and no export that contains them.
Connect them, and issue us a key
Two clicks: open the part of the automation that does the sending, pick the credential you just made, save. Then create a second key, labelled for us, and send us that one. It is what lets us ship you a fix instead of emailing you a file to import, and you can revoke it whenever you like from the same screen.
Revoking it does not stop your automation. It only stops us pushing changes to it.
Nothing sends until the credentials are attached. If you stop halfway, nothing happens — publishing refuses outright rather than going half-live, which is the behaviour we want.
What we can see, and what we cannot
Worth being exact here, because everyone selling this says we never see your keys loosely.
Your credentials: we do not have them. You type them into your own system and it will not give them back, not in the interface, not through any programmatic access, not to any key, not to you.
The key you issue us is a different thing. It manages the automation and reads its run history. It cannot read a credential's secret value — nothing can. But it can change the automation, and the automation uses your credentials. So the accurate sentence is this one: we cannot read your keys out of storage, and we can make your automation act with them, which for a determined party is a distinction without much difference.
That is what us maintaining it for you costs. If you would rather it were not true between updates, revoke our key and reissue it when you want an update. Your automation keeps running either way, and we would genuinely rather you did that than assumed something softer.
The encryption key is handed to the software as an environment variable, which is how it gets read at startup. Anything that can run code on your server can therefore read it, and that includes anything we ship you. What keeps it out of our hands is that we do not retain it and do not go looking, not that the architecture forbids it.
So: we never handle your keys, and they are never exposed to us in normal operation. Both of those are true. Saying that it is cryptographically impossible for us to reach them would not be true, and we are not going to tell you it is. If that distinction matters to your practice, generate the key yourself before we build anything and revoke our access between updates. Both are supported and neither costs you a thing.
What gets recorded, and for how long
Your server keeps a record of each run, including the phone number that was messaged, so that faults can be diagnosed and your monthly summary can count anything at all. Those are deleted automatically after 35 days. They sit on your machine, not ours; we read them over the access you granted, which you can withdraw.
Turning it off, without asking us
Open it and switch it off, top right. Sending stops immediately, nothing is deleted, and switching it back on continues from where it stopped. Or tell us and we will do it — but you own the box, so you never have to wait for us to be awake.