Privacy Policy

The forms on the site ask for your name and email address, and they accept a phone number, a company, and one sentence about what you would point a stream at. If the form asked how many streams you need and how much of the day they would be speaking, those answers are stored too, as you gave them.

Three things are stored that you did not type. Your browser’s user-agent string, cut at 500 characters. Which form the application came from. And a salted SHA-256 hash of your IP address, never the address itself. The hash lets us see one machine flooding the form; it cannot be turned back into an address, and it is not used to identify anyone.

The record gets a short public reference, such as GD-7K4M, and a durable link that opens it. Only a digest of that link is stored. Nothing in the database can be turned back into a working link.

There is no password. Your identity is an email address you have proved, two ways.

The six-digit code. We store your address, a digest of the code, when it expires, and how many wrong tries it has had. The code itself is never stored. It lasts ten minutes, it works once, and five wrong answers end it.

Signing in with an existing account. Your browser hands us a credential the sign-in provider signed, and our server checks it against that provider’s published keys. We read your email address, whether the provider says it is verified, and the name on the account. None of it is written to a database. There is no accounts table at all, the address is the account, and everything you own hangs off it.

Signing in produces a signed session: your address, an expiry fourteen days out, and a signature. It is kept in your browser’s local storage, not on our servers, and it proves one fact, that this browser owns this address.

An order records the plan, the quantity, the term, the address your session proved, a name to put on the letter, and a company if you gave one. It carries the same user-agent string and hashed IP as an application. No price ever arrives from your browser.

Payment is handled by a payment processor. We create a checkout session and send it your email address, the quantity, the price to charge and our own order id. Your card details go to the processor and never reach us. It collects only the billing detail the payment method needs to authorise, which for a card is usually a postcode.

What comes back and is stored is small: the checkout session id, the processor’s customer id, the subscription id if the order recurs, when the paid period ends, whether it is set to stop then, and the moment payment landed. No card number, no expiry date, no billing address.

“Manage billing” opens a one-time link to your own page at the payment processor. Nothing about which customer travels from your browser, the link is built from the session you already hold.

When a payment settles, a key is cut at our engine host under a name derived from your order’s reference, and stored on your order in readable form. That is deliberate. A key exists to be handed back to its owner every time they open the dashboard, so a one-way digest would be a column that cannot do its job. What protects it is the database and a query that names its columns.

Keys are never sent by email and never written to our logs. Two places give one back. The dashboard returns it to the address that bought it, after that address has signed in. The application record at /status returns it to whoever opens that record’s durable link, and the link is the whole credential there, it proves possession of the link, not of the address. Anyone you forward it to can read the key, so treat the link as you would treat the key.

When you type a line into the console and press play, your browser posts that line and a voice id straight to our engine at tts-west.gandr.ai. There is no key on that request and it does not pass through our database. The engine caps it at 200 characters and limits how many casts one address gets a day, so it sees the IP the request came from.

We do not train models on your transcripts, your reference audio, or the audio we generate for you. Your requests are used to render your audio and nothing else.

How the engine treats a render, what is held in memory, what is cached as derived voice features, and the fact that usage is counted as numbers rather than content, is set out in full on our security page, and every line on that page is in force today.

The host the API runs on records the method and path of each request. Credentials never travel in a URL: every endpoint that takes a token or a code takes it in a POST body, so a live credential cannot end up in a request line, a proxy trace or a referrer header.

Our own log lines carry order ids, references, payment ids and error text. When one of us signs in to the review queue, the log records an eight-character hash of the address rather than the address. API keys are never logged.

No passwords, because there are none. No card numbers. No advertising identifiers. The fonts are served from this site’s own origin, so no font host sees your page views either. Cookies are a different matter, and the section on them says which ones your browser does end up with.

Your IP address is a qualified case, and this page used to get it wrong. Nothing we store in our own database keeps a raw one, every IP we write is salted and hashed, and the hash is what the rate limits count. But our analytics provider does receive the address your request came from, and works out an approximate country and city from it. The analytics section below says exactly what that is and how to stop it.

Our own code sets no cookies. Not on the site, not on the API. Nothing we wrote reads or writes one, and the API takes its credentials in a header rather than a cookie on purpose, because those functions answer from a different origin than the page.

That is a claim about our code, not about your browser. Third parties whose scripts run on these pages set their own cookies, and using this site does leave cookies behind. Our analytics provider sets a visitor cookie on every page, as the analytics section below describes. The sign-in provider’s script can set one on /join, where it loads with the page. The embedded booking calendar can set one wherever it appears. The sign-in service behind the older account page can set one there. We do not ask you for cookie consent today; the last section says why that is not settled.

Our own use of your browser’s local storage is small, and only for things you asked for: your signed session and the address it belongs to; the link that opens your application record; a key you paste into the docs or the lab, so it survives a reload. One session-storage flag stops a broken asset reloading the page in a loop. Clearing your browser storage removes all of it and signs you out.

Product analytics is switched on. A key is configured, so every page of this site loads our analytics provider’s script once the page has mounted and sends what it captures to that provider.

It records a page view each time you open a route, carrying the full address of that page, and it records when you leave one. It records eight named product events: pressing a preset in the console (preset_play), starting a cast of your own line (demo_play_started), finishing one (demo_play_completed), hitting the console’s character cap (demo_cap_hit), opening the buy page (buy_viewed), starting a checkout (checkout_started), a payment settling (payment_completed), and your key being shown on the dashboard (key_displayed).

What travels with those events is which preset you pressed, the voice and language you picked, how many characters you typed, what the engine answered, and the plan, quantity, term and public reference of an order. No event carries your email address, your name, or your API key.

The analytics provider receives the IP address your request came from, as any server you connect to does, and it keeps it on the event and derives an approximate country and city from it. We use that to see where the people arriving on a given day came from, nothing more granular than a city, and it is never joined to your name or your email. An IP address is personal data under the GDPR, which is why it is named here rather than left to a default. Blocking that provider’s script, an ad blocker will do it, stops all of this, including the address, and the site works normally without it.

We have not turned off that provider’s own automatic capture, so it also records clicks on the page and the text on the thing you clicked. It keeps a visitor id in your browser, in local storage and in a cookie, so it recognises the same browser across visits. That id is a random string rather than your address.

Error reporting is wired and switched off. An error reporter exists in the code and is inert: nothing is configured for it to report to, so no script is fetched and no error leaves your browser. If we switch it on it would send the error, its stack and the page it happened on, and this page will say so before it starts.

An earlier sign-in still works at /account and is served by a hosted sign-in service. Opening it loads that service’s script and signs you in against an instance whose home domain is gandr.ai. It holds that account record; we read the email address on it and the metadata attached to it. The current door is /join, which fetches its sign-in script as the page draws rather than when you press anything, so that provider sees the visit whether or not you use the button.

To do what you asked. Your address, your order and your key exist so you can sign in, pay, and get the thing you paid for.

To keep the service standing. The hashed IP and the rate-limit counters exist to stop one machine burning the mail allowance that real customers’ sign-in codes and receipts depend on.

To answer an application. If you asked us to call you, we hold what you told us so we can call you. Your address is used to answer your request and is never added to a list.

Because the law requires a record of a payment. Accounting and tax records of money that moved.

To see how the site is used. The analytics described above measure which pages get opened and which of eight product steps get reached. We have not settled what that measurement rests on where the law asks for consent, and the last section says so rather than choosing an answer here.

Running this service means other companies are in the path: a database host, the host the API runs on, the host that serves this website, an email provider, a mail forwarder, a payment processor, an analytics provider, a sign-in provider, a booking calendar, and the rented machines your renders run on. We do not publish which companies they are. That list is commercial information about how this business is built, not a fact about your data, and naming it here serves our competitors rather than you.

What each one receives is set out above and does not change by leaving the names out: the payment processor takes the card and we never see it; the analytics provider receives the page views, the events and the IP address your request came from; the email provider handles the address, the subject and the body of anything we send, and the forwarder handles anything you write to us; the sign-in provider sees your email address and name only if you use it; the booking calendar receives the name, address and time of any call you book; and the render path receives the text you send and any reference audio, which is not kept after the render.

We do not sell personal information and we do not share it for advertising. If you need the companies by name, a security review, a procurement questionnaire, your own compliance record, write to contact@gandr.ai and we will send the full list, each one with what it is used for and what category of data reaches it. That is a written answer to a named person, not a page our competitors can read.

Sign-in codes: ten minutes. A code is deleted the moment it is used, and after five wrong tries. A sweep clears anything left a day past expiry.

Applications and orders: nothing in the service deletes them. There is no scheduled job and no expiry on those rows, so they are kept until you ask us to remove them or we no longer need them for accounts. We have not set a fixed period yet, and we would rather say so than publish a number we do not enforce.

Rate-limit counters: one row per bucket, keyed to a hashed IP or a hashed address. The count resets at the end of each window. The row itself is not deleted.

Email, payments and the render path: our email provider and our payment processor keep their own records under their own retention, and a payment processor has obligations of its own about payment history. What the engine holds during and after a render is on the security page.

You can ask what we hold about you, ask us to correct it, ask for a copy, ask us to delete it, or object to us holding it. Depending on where you live you may also have a right to complain to your data protection regulator.

Two of these need no request at all. Sign in at /dashboard and you can read every order that address owns, including your key. Open your application at /status and you can read the record and its dated history.

For anything else, write to contact@gandr.ai from the address on the account. We answer every one. If we have to keep something, a record of a payment, most likely, we will tell you what and why rather than quietly keep it.

Traffic is encrypted in transit. Codes, application links and reviewer sessions are stored as digests, never in the form that would open anything. IP addresses are salted and hashed. Every query that returns a record names its columns rather than selecting everything, so a column added next month cannot leak by default. Every endpoint a stranger can reach without a credential is rate limited.

We hold no security certification. Formal certification, SOC 2 included, is on the roadmap and is not complete, and our security page says the same. No method of transmission or storage is completely secure, and we do not claim otherwise.

Gandr is sold to businesses and to people building software. It is not directed at children, and we do not knowingly collect personal information from a child. If you believe a child has given us information, write to contact@gandr.ai and we will remove it.

We update this page when the service changes, and the date at the top is when it last changed. If a change means we start collecting something we did not collect before, the page is updated to say so.

We are two people and we say only what is true, so the gaps are listed rather than filled with language.

We do not publish a legal entity name, a registered address or a governing law here yet. We have no signed data processing agreement to offer. We have not set a fixed retention period for order and application records, or a stated deadline for answering a rights request.

Analytics is running and this site asks for no cookie consent before it runs. We have not settled whether it should, what the measurement rests on where consent is required, or how long the analytics provider keeps what it receives. Until that is settled we would rather the page said the collection is happening than imply a permission we have not asked you for.

If your review needs any of these in writing, ask at contact@gandr.ai and you will get an answer from a person rather than a page.

Questions about this policy, or a request about your own data, go to contact@gandr.ai.