Legal
How Parlabase handles data
Version 1.1 · Last updated: 12 October 2026
This page is not part of any contract.
It describes how the Service works today, at the detail a figure needs, and it changes as the product changes. What we owe you is in the Terms of Service, the Privacy Policy and the Data Processing Terms, and they take precedence: where a figure below is shorter than a ceiling one of them states, the figure is what we do today and the document is what we are bound to.
1. The transcript
The most recent stretch of the transcript is held in the live server’s memory, older lines falling away as new ones arrive, while the session runs and for 60 minutes after the last person disconnects, after which it is discarded. It is also lost on any restart of that server, so it is not a record to rely on.
The transcript of every broadcast is written as the broadcast runs, to storage under the organisation’s own path, and rendered when it is asked for. A host removes it per broadcast or with the whole session, and it goes with the account. Removing it also asks each provider that handled the session’s audio, and that gives us a way to ask, to delete its own copy; which providers those are is on the Sub-processors page. A guest who asked for the transcript by email receives it as attached files.
Current behaviour. The documents above govern. What we undertake is in Annex 1, Retention, of the Data Processing Terms and Deletion and return there.
2. A guest’s email address
Where a guest asks for a copy of a session by email, we hold the address they gave. Before we send anything to it we send that address a confirmation link, and send nothing else until it is confirmed. An address that is never confirmed, and anything still waiting on it, is removed after 7 days with no confirmation, counted from its last request.
Once confirmed it serves that organisation’s later sessions too, and a further request to it is not confirmed again. It is used for nothing else. It is removed when the guest removes it themselves — by the link in an email we sent them, which lasts as long as the address from that request would be kept, or by asking us — or when 365 days pass with no further request to that organisation.
Current behaviour. The documents above govern. The ceilings are in Annex 1, Retention, of the Data Processing Terms.
3. Backups
Copies age out on a rotation: a copy is currently deleted 90 days after it is taken, inside the 120 days the Data Processing Terms commit to.
Current behaviour. The documents above govern. The ceiling is in Annex 1, Retention, of the Data Processing Terms.
4. What we store on your device
These are the keys and lifetimes behind What we store on your device, of the Privacy Policy, which explains the exceptions named in the last column and carries the controls for refusing what can be refused.
| What is stored | What it is for | How long | Exception relied on |
|---|---|---|---|
| Session cookie the product | Keeps you signed in to the app. | Until you sign out, or your organisation’s session policy expires it — 7 days unless it sets otherwise. | Strictly necessary. |
| Sign-in state cookie the product | Protects the sign-in exchange against cross-site request forgery. | 10 minutes. | Strictly necessary. |
| Re-authentication cookie the product | Records that you have just confirmed who you are, so a sensitive action does not ask twice over. | 2 minutes. | Strictly necessary. |
| Sign-in service session cookie the product | Your session at the sign-in service, so signing in once covers the apps you use. | Up to 30 days. | Strictly necessary. |
Stripe cookies (__stripe_mid and __stripe_sid)the product, on billing pages | Set by Stripe, our payment processor, to tell a genuine payment from a fraudulent one. Stripe sets and reads them, not us; Stripe’s own privacy documentation describes them. | __stripe_mid about a year; __stripe_sid about 30 minutes. | Strictly necessary. |
parlabase-themethis site | Remembers whether you chose light or dark, so the next visit does not flash the wrong theme. If you have not chosen, we follow your device setting and store nothing. | Until you change it, refuse it on the Privacy Policy, or clear this site’s data. | An appearance you chose. |
parlabase:interest-idempotency-keythis site | A one-time reference sent with your enquiry, so a double-click or a resubmit is recorded once instead of twice. It identifies the enquiry, not you. | Deleted as soon as the enquiry is sent; otherwise until you clear it on the Privacy Policy, or clear this site’s data. | Strictly necessary. |
parlabase:signed-in-hintthis site | The answer to the signed-in check below, so each page knows which sign-in link to show. | The tab: it is sessionStorage, so it goes when the tab closes. | Strictly necessary. |
| The signed-in check this site reads it, and stores nothing | Asks the product whether you are signed in, so the link can take you to the app rather than to sign-in. Your browser sends the product’s own session cookie to the product’s address; this site does not see its value. | Once per page load, or once per tab where the answer above is remembered. | Strictly necessary — authenticating you. |
parlabase-themethe product | The same light or dark choice, stored separately for the product. | Until you change it, choose to follow your device setting, or clear the product’s data. | An appearance you chose. |
audio-settingsthe product | A host’s microphone and audio preferences, including the voice-detection settings that decide when speech is sent for transcription. | Until changed or cleared. | Strictly necessary — a record of settings you put in. |
parlabase:broadcast-resume:<session>the product | A note that this tab was broadcasting when it had to confirm who you are, so the session picks up again instead of waiting for you. | The tab: it is sessionStorage, and it is cleared as soon as the session picks up again. | Strictly necessary. |
listener-prefs:<session code>the product | The language a guest chose to read a session in and, if they asked for the transcript by email, the address they gave, so a reload does not ask again; and a random reference, so a dropped connection rejoins as the same guest — in their own place, counted once. | The tab: it is sessionStorage, so it goes when the tab closes. | Strictly necessary — a record of selections you made, and rejoining after a dropped connection. |
Current behaviour. The documents above govern. What we undertake is in What we store on your device, of the Privacy Policy.
5. Closing an account
When a host account closes — see Closing your account, of the Terms of Service — two clocks start and run independently.
Session content and the guest contact information attached to the account are currently deleted 30 days after the account closes, on the same day the Data Processing Terms give for deletion after the Service ends. A reminder email goes to the account owner and billing contacts 7 days before that deletion runs, because it is the one step that cannot be undone.
If a copy was requested before that happens, the download link we send is valid for 7 days; deletion waits until it has expired.
The account record is kept for 12 months after closure and is then redacted; invoices and payment records follow the longer tax period in Retention, of the Privacy Policy.
Current behaviour. The documents above govern. What we undertake is in Deletion and return, of the Data Processing Terms and Retention, of the Privacy Policy.
Version 1.1 · Last updated 12 October 2026
- 12 October 2026 — Pay as you go in the Terms and the Privacy Policy; the organisation name in the Privacy Policy; a network as a ground for withholding the welcome minutes; the 90-day ceiling on logs and security data; session and broadcast wording in the Data Processing Terms; the enquiry link's lifetime on the data-handling page; a guest's rejoin reference on the device, and counting how many people joined a session
- 18 September 2026 — First published.