# Privacy Policy

**Last Updated: 23 October 2026**

This Privacy Policy explains how Lumman Ltd handles information in connection with this website, lumman.co. It covers this website only. Other Lumman products and services have their own privacy policies.

## 1. Who We Are

lumman.co is operated by **Lumman Ltd**, a company incorporated in England and Wales (Company Number: 15425759) with its registered office at 86-90 Paul Street, London, EC2A 4NE, United Kingdom. For the purposes of UK data protection law, Lumman Ltd is the data controller for this website.

You can reach us at in [at] lumman [dot] co.

## 2. The Short Version

The public pages of this website are static and informational. They have no accounts, no sign-in, no forms, no payments, and no chat: we do not ask you for personal information there and we do not build a profile of you. We use privacy-friendly, cookieless analytics to understand aggregate traffic, and nothing more. The account and connectors in sections 3.4 to 3.6 are a separate, signed-in service, and what they hold is set out there. A Multi Calendar booking link someone sends you, or a Multi Calendar booking page, opens one of the two pages here that ask for your name and email address, a Multi Calendar group poll's link made for you opens a page that asks for neither, and section 3.5 sets out what happens to what each is given.

## 3. What We Collect

### 3.1 Anonymous Usage and Performance Analytics

We use Vercel Web Analytics and Vercel Speed Insights to measure aggregate page views and page-load performance. These tools are privacy-friendly: they do not set tracking cookies, do not use cross-site identifiers, and do not collect information that identifies you personally. The data we see is aggregated (for example, how many visits a page received), not individual.

### 3.2 Information Stored on Your Own Device

Your browser keeps four small notes in its local storage on your device: that you last signed in here with a passkey, that this device answered it holds no passkey for this site, that you have answered the offer to add one, and when you last put off checking a way into your account unused for six months, which keeps that reminder off this device for a month. They name no account, stay on your device and are never sent to us. Clearing this site's data in your browser removes them.

### 3.3 Hosting and Security

The website is hosted by Vercel. To deliver and protect the site, our hosting provider processes standard technical request data (such as your IP address) transiently, as any web host does. This is handled under Vercel's own privacy and security terms and is not used by us to identify you. On the sign-in screen, the connector page, the approval screen and every booking page, booking link and poll, Vercel's bot protection also reads signals from your browser to tell a person from an automated program.

### 3.4 Multi Mail

**Multi Mail** - A connector that gives your AI client your own Gmail, Outlook, iCloud and Fastmail mailboxes. This section covers everything it touches.

**What it reaches, and why.** If you connect a Gmail account to a Lumman account with Google sign-in, we ask Google only for the permissions the connector needs to act for you: reading and searching your mail, composing and sending it, organising it with labels and filters, and reading and changing your signature and vacation responder. Each of those is asked for because your AI client can be asked to do it for you, and for no other reason. We never ask for the permission to delete mail permanently, and no tool here empties a bin. A Microsoft mailbox is the same connector asking Microsoft for the same work, but Microsoft offers no mail permission narrower than one that also deletes: Microsoft's mail permission also allows deleting mail. In a Microsoft mailbox the connector never deletes a message, and the only files it deletes are those an Outlook draft held before your AI client rewrote it with a new list of files - from the sent copy too, if that draft is sent at the same moment.

An iCloud or Fastmail mailbox is connected with an app password you make for Lumman at Apple, which calls it an app-specific password, or at Fastmail, and that password opens the whole mailbox. We send it to that provider's receiving mail server and, once that accepts it, to its sending mail server, each only after the server proves who it is; we keep it only once both have accepted it, and afterwards send it to those two servers alone. In such a mailbox a message the connector moves - archived, binned, restored, junked or filed under a label - is copied to its new folder and the copy left behind is removed for good; an edited draft is stored anew and its old version removed for good; and a sent draft is removed from Drafts for good once it has gone. No other message is removed, and deleting a label deletes its folder only when the folder was found empty.

A Gmail or Google Workspace account can instead be connected with an app password you make for Lumman at Google, which Google describes as giving an app access to your Google Account. We send it to Gmail's receiving mail server and, once that accepts it, to its sending mail server, each only after the server proves who it is; we keep it only once both have accepted it, and afterwards send it to those two servers alone. In such a mailbox archiving, labelling, binning, restoring and junking change a message's labels as Gmail's own buttons do, and no message is removed; an edited draft replaces its old version and a sent draft leaves Drafts while its sent copy stays, as in Gmail itself; and deleting a label deletes it only when it was found empty.

**What is kept, where, and for how long.** We keep no copy of your mail. Messages, threads, attachments and drafts are read from the mailbox's provider when you or your AI client ask for them, and nothing read that way is kept here.

What we do keep is held in our database and its file storage, both operated for us by Supabase and hosted in London:

- the credential that mailbox's provider issues for it - or, for a mailbox connected with an app password, the app password you gave us and the two mail servers it was checked against - encrypted, together with the minimal technical state a durable connection needs - the address, the name you gave it, which provider holds it, and the permissions that provider granted. It is kept until you disconnect that mailbox or delete the account, and no longer;
- a record of what the connector was asked to do - the tool, the mailbox, the identifier of whatever the call touched, how many recipients a send named, and whether it succeeded. That record never holds a subject, a body, a recipient or an attachment, and it is kept until the account is deleted;
- for each clear-out of a mailbox an AI client previews, which messages each of its groups counted - by the provider's identifiers for them and, for a mailbox connected with an app password, each message's own Message-ID, which often names the domain it was sent from, the folder or label each came from and what the clear-out did with it, never a subject, a sender or a recipient - so that only what was counted moves and what moved can be put back. It can be put back for seven days after the clear-out is applied, and is deleted within minutes of that, or of an hour after the preview where it is never applied - and at once when you disconnect that mailbox or delete the account;
- for each account, the hour of its latest mailbox password check and how many checks in that hour the provider refused, which bounds how many may be tried. It is kept until the account is deleted;
- a file your AI client hands over by uploading it for a draft or a message, held only to carry it there and read only by your own account's calls. It is deleted once it is carried and, carried or not, within the hour of its upload, even where the account closes first.

**Which AI clients it is passed to, and on whose approval.** What the connector reads is passed to the AI client you approved for this connector, and to no other. Any AI client can ask for that approval - we keep no list of permitted ones, and a client registering with us gains nothing by it. None reaches a mailbox of yours until you have approved it yourself on our own approval screen, which names the client and every address it would be answered at, and taking that approval back stops it at its next request. Each answer about a file also gives that client a link to the file itself: for one hour after it is given, whoever holds the link gets the file, whole, from your mailbox's provider, with no sign-in - so a client that passes the link on passes the file on. Taking that approval back, closing the account, disconnecting the mailbox or turning off reading its attachments stops every such link at its next use, and giving the approval or the reading back within that hour opens it again.

**Screening.** Before mail moves, its words are screened for prompt attacks by Google Cloud's Model Armor, a security service acting as our processor: what a mailbox answers, before it reaches your AI client, and the words a draft or a message carries, before they reach the mailbox's provider. It receives only the words being screened - subjects, message text, the addresses a message names, the names of the files it carries, the words of a file your AI client asks to read, and the words printed in a picture the connector's answer carries - and nothing we hold about you or your account; it processes them in the European Union and is configured to keep no copy of them, so nothing of what it screened is retained there or here. A file's own bytes are never sent to it: any other file handed over as it is, including a picture fetched whole from the address the connector names for it, is screened by its name alone, and every file a draft or a message carries is passed on unscreened. Content it screens as an attack is refused, and a screening that cannot be completed closes that call rather than moving anything unscreened.

**Disconnecting.** Disconnecting a Gmail mailbox connected with Google sign-in withdraws the authorisation at Google and deletes the stored credential. Disconnecting a Microsoft mailbox deletes the stored credential, which is the whole withdrawal available to us: Microsoft offers no way for an application to end its own authorisation, so Lumman stays among the apps you approved at Microsoft until you remove it there - at account.live.com/consent/Manage for a personal account, or myapplications.microsoft.com for a work or school one. Disconnecting a mailbox connected with an app password deletes our copy of it; the password itself keeps working until you delete it - at account.apple.com under App-Specific Passwords, in Fastmail's settings under Privacy & Security, or at myaccount.google.com/apppasswords. We never discard a credential on our own initiative.

**Google's Limited Use requirements.** Lumman's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. In full, that means:

1. **Use.** We use what the connector reads from your mail only to provide and improve the features of Multi Mail that you can see on this site, and for nothing else.
2. **Transfer.** We transfer it only where that is necessary to provide those features - to the AI client you approved, to whoever holds a link it was given to a file, and to the screening service above - or where the law requires it, or in connection with a merger or acquisition, and then only after telling you and obtaining your agreement.
3. **Human reading.** No person reads it, except where you ask us to for a specific message, where it is necessary for security, such as investigating abuse, or where the law requires it.
4. **Prohibited uses.** We never use it for advertising of any kind, we never sell it, we never use it for credit decisions or any assessment of creditworthiness, and we never use it to train a generalised artificial-intelligence model. Your own AI client acts on your mail at your request; that is the only model use there is.

### 3.5 Multi Calendar

**Multi Calendar** - A connector for your own Outlook.com, Microsoft 365 and Google calendars.

**What it reaches, and why.** If you add a Microsoft account's calendars to a Lumman account, we ask Microsoft for permission to read and change the calendars in that account, and to read the account's address and identifier. Microsoft offers no narrower permission that would let the connector create, change or cancel events and answer invitations on your behalf. It reads the names of your calendars, which it shows you on the connector page, and - when an AI client you approved for it asks - your calendars and the events of the period that client names, or one event whole with its full description when that client asks for it, which it passes to that client. Their words - your calendars' names, each event's title, place, description and meeting links, the names and addresses of its organiser and guests, and the identifiers of a Google event and of a Google calendar named by an address, which whoever made them may choose - are first screened by Model Armor, as section 3.4 describes, and an event whose words it screens as an attack is left out alone and the rest passed on, that client told only when the event is and each copy's account, calendar and identifier - each copy's account alone where those identifiers screen as one. When that client asks, it also creates, changes and cancels events and answers invitations, and Microsoft sends each invitation, update, cancellation and answer from that account's own address; the words such a request carries - a title, a place, a description - are screened by Model Armor before they reach Microsoft.

**Google calendars.** If you add a Google account's calendars, we ask Google - through Lumman's own Google calendar client, registered with Google apart from the one Multi Mail's Gmail access goes through - for permission to see the list of your calendars and to see and change their events, and for the account's address and Google's identifier for it. The connector reads a Google account's calendars and events, creates, changes and cancels its events and answers its invitations as it does a Microsoft account's, screened the same way, and Google sends each invitation, update, cancellation and answer from that account's own address. What it reads from Google is held to the Google API Services User Data Policy and its Limited Use requirements exactly as section 3.4 sets them out for mail, with three further transfers: for a Google calendar you name another of your accounts for under busy everywhere, below, when each busy event starts and ends, under a title naming that Google account's address, is written into the main calendar of each account you named for it, at its own provider; a booking link or booking page shows its guest the free times described below; and a circle you are in passes when your busy events start and end to the AI client of a member who asks, as described below.

**Busy everywhere.** On the connector page or through an AI client you approved, you can name another of your connected accounts to show the busy time of one of a connected account's own calendars. The connector then reads that calendar every few minutes and whenever Google or Microsoft tells us it has changed, with no AI client asking, for when each event of the coming 60 days starts and ends and whether it shows you as busy - never what it says. For each busy time it places a private block titled "Busy ·" followed by the address of the calendar's account and "(Multi Calendar connector)", with no place, description or guests, in the main calendar of each account you named for that calendar, while that account allows changing events - never in an account you did not name, the calendar's own account, another calendar or one shared with them - one block however many calendars named for that account hold that time. Being private, the block shows only as busy to anyone who may only see that calendar; anyone allowed to change it or to see its private events reads its title, and with it that address. It moves the block when its event moves, places it again if it is removed by hand, and removes it when its event ends, moves past those 60 days or goes, or once you take the pair away. Turning off seeing events for the calendar's account, or changing events for the account holding the block, takes the pair away too. When an AI client you approved reads your calendars, the connector shows it when each block stands, which account it copies and which accounts hold it - never as one of your events - and never lets it move or cancel one, or counts one as your busy time.

**Booking links.** When an AI client you approved asks, the connector makes a booking link offering the times you choose for a meeting you name. Anyone you send it to can open it without an account and book one of its times once, giving a name and an email address; the page shows each time in your time zone, under its name, and first in the visitor's own where their device reports a different one - read by their browser and never sent to us. A time that stops being free before it is booked is replaced by other free times up to the link's last one, which the connector picks from the calendars it reads, as below, and your preferences; a guest sees those times and nothing else of your calendars. When a time is picked, the connector - with no AI client asking - reads when the events of every calendar that counts as busy start and end, and of the calendar you named to receive bookings even where it does not count as busy or its account's events are kept from AI clients; it books the time only where it is still free in all of them and within your working hours, the time kept free around a meeting, the least notice and the most meetings in a day, and creates the meeting in the calendar you named to receive bookings, and Microsoft or Google sends the invitation from that account's own address. The guest's name and address are not kept here: they go into that invitation, so they stay in your calendar at Microsoft or Google.

**Booking pages.** You can set up a booking page - or, with the Multi Calendar plan, as many as you like - on the connector page or through an AI client you approved: each answers at lumman.co/book/ followed by a name you choose, and books a meeting you name. Anyone can open one without an account. Each time a page is opened, the connector - with no AI client asking - reads when the events of every calendar that counts as busy start and end, and of the calendar receiving bookings, as for a booking link, and the page shows the free times within your working hours and your other preferences over the coming 14 days, shown as a booking link's page shows its times; a guest sees those times and nothing else of your calendars. A guest books one by giving a name and an email address, the connector reads those calendars again, and the meeting is created as it is for a booking link. Nothing of the guest is kept here. Each visit counts the requests it makes of the connected account it asks most - one for that account's list of its calendars, one for each of its calendars it reads - and once your pages together have counted 120 in a minute, a page tells its visitor it is busy and to try again shortly, and reads nothing until the next minute. You can remove a page on the connector page: it stops answering at once, and a meeting already booked through it stays in your calendar. A name one of your pages has carried stays yours: no other account can take it after you rename or remove that page.

**Group polls.** When an AI client you approved asks, the connector makes a poll offering the times you choose for a meeting you name, for the people whose addresses you give. Each address gets its own link, given to that client, and we keep a one-way digest of each link - never the link itself. We send the people the poll is for nothing: you share each link yourself, or that client sends it from your own mailbox. Whoever opens a link needs no account and gives no name or email address: they tick the times that address can make, answering again replaces that address's answer, and the page shows the times as a booking link's does, and never anyone else's answer. We keep the addresses the poll is for and each one's answer, and pass them to that AI client when it reads the poll, first screened by Model Armor. When that client books one of the times, the connector - as for a booking link - reads when the events of every calendar that counts as busy, and of the calendar you named to receive bookings, start and end, creates the meeting in that calendar, and Microsoft or Google invites exactly the people the poll is for from that account's own address, so their addresses stay in that invitation. The addresses and answers are deleted here when the poll is booked or closed, or 14 days after it is made if it is not, and its links then find it closed.

**Circles.** You can create a circle and invite people into it by email address, on the connector page or through an AI client you approved. Either way we email each address ourselves, through Resend, a letter that carries your address as its sender's name, names the circle, says how to join and sends replies to you; inviting an address already invited there sends nothing new. Through an AI client the circle's name is first screened by Model Armor, and no letter goes for a name that screens as a prompt attack. An account sends at most 20 such letters in any 24 hours, however they were asked for, and an address whose letter Resend refuses is not invited. Only an account signed in at the address invited can join, and a withdrawn invitation cannot be joined. If an address you invite already holds a Lumman account, its letter is shorter and the invitation also waits in that account, which can join it there or decline it; a decline hides it from that account alone, so you still see the address as invited, and its letter can still join it. Someone you invite joins through their letter, signing in to a Lumman account at that address and connecting a calendar; anyone signed in at another address is refused and told nothing of the circle. Each member sees the circle's name and the address of everyone who has joined it, and can leave it at any time. When an AI client that you or another member approved asks for a time free for the circle, the connector reads when the events of the calendars each member owns and counts as busy start and end - the owner's included, never a calendar someone else shared with a member - through that member's own connection at that moment, and passes that client only those times and whose they are, never what an event says, keeping none of it. You can remove a member or delete the circle, and neither is read for it again. A member's time zone, as they stored it, is passed to the AI client of another member who finds a time for the circle or invites them, at the address invited, to a meeting or a poll - the owner's only to one who finds a time - so that client can give the member's own time and hold an invitation outside 09:00-18:00 or on a weekend there until its sender agrees.

**What is kept, where, and for how long.** We keep no copy of your calendars. What we keep is held in the database described in section 3.4: the credential Microsoft or Google issues for calendar access, encrypted, together with the account's address, that provider's identifier for it, the permissions it granted and which of seeing, changing events, and inviting and replying you allow on it. It is its own credential even for an account also connected to Multi Mail, and it is kept until you disconnect that account's calendars or delete the account, and no longer. We also keep a record of what the connector was asked to do - the tool, the account a call named, and whether it succeeded. That record never holds anything an event or a calendar says, and it is kept until the account is deleted. We keep your scheduling preferences - your time zone, working hours, default meeting length, the time kept free around a meeting, the least notice, how far ahead a meeting may be, the most meetings in a day, preferred times, which calendars count as busy, which calendar receives bookings and a default meeting link - as you or an AI client you approved set them, and pass them to that client when it reads them, finds a time or creates an event for you; a meeting link such a client sets is first screened by Model Armor. Such a client changes your time zone only on your word, and where none is stored, opening the connector page stores the time zone your device reports. They are kept until you change them or delete the account, as are the latest minute your pages read your calendars in and how many requests they counted then, and each booking link and poll - its meeting's name and length, its time zone, the times it offers, whether it has been booked and the time booked - a poll's addresses and answers going sooner, as above. Each booking page's name, its meeting's name and length, when it was made and the time of each booking it takes are kept until you remove that page or delete the account. Each name a page of yours has carried is kept, as yours, until the account is deleted. For each pair you name for busy everywhere we keep the calendar and the account it shows busy time in, until you take the pair away, seeing events is turned off on the calendar's account or changing events on the other, either account's calendars are disconnected, or the account is deleted. For each busy block we keep which event it copies, which calendar holds it, the provider's identifiers for both, the event's version and a digest of the block's title - never when it is - for as long as the block stands, or until either account's calendars are disconnected or the account is deleted. For each Google calendar a pair names, and each Microsoft account one of whose calendars a pair names, we also keep the standing request asking Google or Microsoft to tell us of its changes - which calendar or account it covers, the provider's identifiers for it, when the provider ends it and a one-way digest of the secret each of its notices must carry, never the secret - until a new request replaces it, the connector next finds no pair naming that calendar or a calendar of that account, or that account needing reconnection, that account's calendars are disconnected, or the account is deleted. Microsoft tells us of a change to any event in the account, of which only the calendars you named are read. A notice from Google says only that the calendar changed, and one from Microsoft only which event changed - never what it says - and nothing of either is kept; either provider may go on sending them for up to a week after a pair goes. For each circle we keep its name and when it was made until you delete it or the account, and for each invitation the address you invited until you withdraw the invitation, delete the circle or delete the account; if the person invited declines it, we keep which account declined, seen by no one else, until the invitation goes or that account is deleted; once the person invited joins, we also keep which account joined, until they leave, you withdraw their invitation or delete the circle, or either account is deleted. For each invitation letter we send for you we keep when it was sent - never to whom - until the account is deleted, which is what counts the 20 a day.

**Disconnecting.** Disconnecting an account's calendars deletes the stored calendar credential and leaves any Multi Mail connection to the same account as it is; for a Google account it first withdraws the calendar authorisation at Google, which leaves a Gmail authorisation as it is. Microsoft offers no way for an application to end its own authorisation, and it holds one approval of Lumman for both connectors: Lumman stays among the apps you approved at Microsoft until you remove it there, as section 3.4 describes, and removing it there ends both.

### 3.6 Your Lumman Account

Anyone may create a Lumman account by signing in with Google or with Microsoft, or with a code we email to any address. From a Google or Microsoft sign-in we receive only what it carries: the address of the account and that provider's own identifier for it; a code sign-in carries the address alone. Beside that we store what the account has been opened for, and the country our host placed its first sign-in in, never the connection's address, until the account is deleted. Where the visit that made the account came to this website from another one, we also store that website's domain - never the page, a search or anything else about the visit - to count where accounts come from, until the account is deleted; a visit that makes no account leaves no such domain with us, and none is kept in the browser. Asking for a code makes the account at once, holding that address and nothing else; it reaches nothing until a code sent there is entered, and if none ever is, it is deleted a day after the last code was sent. We use the account's address to send it sign-in codes, service notices about the account and its connectors, and news and offers about our connectors; our email provider, Resend, sends them for us, and a record of which notice reached the account is kept until it is deleted. Every email of news or offers carries a link that stops all of them in one click, without signing in, and we keep when it was pressed until the account is deleted. An account may also hold a passkey, added on the connector page once the account exists; signing in with it carries neither an address nor a provider identifier, because the device proves the account the passkey was enrolled against. Once the account holds a passkey or a Google or Microsoft sign-in, sign-in by emailed code can be turned off on the connector page, and we keep when it was turned off until it is turned back on or the account is deleted. While it is off, a code sent to the address signs nobody in and a Google or Microsoft account the account does not already hold is not added to it; turning it off signs no one out, and an account left with no other way in signs in by code again. The connector page lists every way into the account - each passkey with where it is kept and when it was last used, each Google or Microsoft sign-in with its address and when it was last used, and the emailed code - and a Google or Microsoft sign-in can be removed there, which signs no one out. We keep when each Google or Microsoft sign-in was last used until it is removed or the account is deleted; what a removed sign-in carried stays in the account's record until the account is deleted. The connector page also lists every browser the account is signed in on, each named by the description of itself that browser sends us, which we keep with its sign-in until that browser is signed out or the account is deleted, beside when it was last active; one other browser or every other browser can be signed out there, and the AI clients the account approved stay connected. The same list shows each AI client the account is connected to, by the name it gave itself and the addresses it was approved at, beside when it was last active; disconnecting one there takes back everything it was approved for, on every connector. When the account signs in from a browser it has not signed in from before - never at its very first sign-in - approves an AI client it never approved, connects a mailbox or calendar account it does not already hold, turns sign-in by emailed code on or off, or removes a Google or Microsoft sign-in, we email its address saying what happened, when, the browser and device, and the country and city our host placed the request in, a place we do not keep; these emails go to every account and cannot be turned off. Their It wasn't me button works without signing in: one press signs every browser and AI client out of the account and takes back what the email says was added - that browser is no longer one the account knows, that AI client is disconnected, that mailbox or calendar account is disconnected, or sign-in by emailed code is turned off again where the account holds another way in; a code turned off or a sign-in removed stays as it is. When a Google or Microsoft sign-in joins an account that already existed, however that sign-in went, or a passkey is added to or removed from the account, however that was done, we email its address within minutes saying what changed and when, and keep that sign-in's provider and address, or which passkey it was, only until the email has gone; its It wasn't me button also removes the sign-in or passkey added, unless it is the account's last way in besides an emailed code that is off, when it stays, and a passkey removed stays removed. To tell a new browser from one the account knows, a browser that starts a sign-in here keeps a random mark in a cookie (section 5), and we keep a one-way digest of each browser's mark with when it first and last signed in to the account, until It wasn't me is pressed on that browser's email or the account is deleted.

Holding an account is not access to all of it. A mailbox needs no invitation at any provider: anyone signed in connects one and approves an AI client for it - though Google's own preview admits a limited number of accounts, so once that room is gone a Gmail or Google Workspace mailbox connects with an app password instead. An account on Google Workspace can join a list for Google sign-in, as any account could while Gmail was refused: we keep the moment it joined and nothing else, write to the account's own address once, the day Google sign-in can add its mailbox, and delete its place when it leaves the list or the account is deleted. Accounts that signed in with Google after that room ran out and held no Gmail mailbox were put on the list for that message, and can leave it the same way. Anything we have not released works only once we have opened the account for it, which we do by hand. Until then the account reaches none of it, and it is told so where it asks.

You can close the account yourself at any time, on the connector page, and closing it deletes everything. From that moment it reaches nothing; every subscription it pays for is stopped, every authorisation we can withdraw is withdrawn, and everything held here that names you is destroyed. It cannot be undone. Section 8 sets out what survives that and for how long, and the Data Deletion page at lumman.co/data-deletion carries the steps.

While sign-in by emailed code is off, the email a code request gets also offers to start over, for someone who can no longer sign in any other way. Confirming it, without signing in, asks for the account to be closed, and we keep when that was asked. Signing in to the account within seven days, or pressing Cancel on the connector page, withdraws the request, and while it stands every AI client the account approved is told of it in each answer. Otherwise the account is closed seven days after the request, exactly as if you had closed it yourself, and a new, empty account can then be made at that address.

### 3.7 Payments

Multi Mail's and Multi Calendar's plans are sold through our payment provider, Polar, which acts as merchant of record and takes the payment. Your card details go to Polar and never to us: we neither see nor store them. From Polar we keep only what a subscription needs - its identifier there, the connector and account it is for, its state, the capacity it confirms, its interval, and when we last agreed with Polar about it - along with the notifications Polar sends us about it.

## 4. What We Do Not Collect

Because the public pages have no accounts, forms, payments, or chat, we do not collect or store through them: names, email addresses, passwords, payment or billing details, account or subscription data, chat or conversation history, or advertising and cross-site tracking data. If you email us at in [at] lumman [dot] co, we will of course see that message - but that is your direct choice, not data this website gathers. The sign-in screen asks for the email address a code is sent to, kept as section 3.6 says. A booking link's page and a booking page are the only other forms that ask for a name or an email address, a poll's page asks only for the times that suit, and section 3.5 says what each does with what it is given.

## 5. Cookies

This website does not set tracking or advertising cookies. A browser that starts a sign-in here keeps a cookie from us holding a random mark, for 400 days after it last did, which tells a browser an account has signed in from before from a new one (section 3.6). The sign-in notes described in section 3.2 use your browser's local storage, not a cookie. Our analytics provider is cookieless.

## 6. Sharing and Disclosure

We do not sell, rent, or trade personal information. Every party that processes what the connector reaches is named here: Vercel, which hosts this website, provides the privacy-friendly analytics above and checks for bots when a sign-in code is asked for, a mailbox password is checked, or a guest books a time or answers a poll; Supabase, which operates the database and file storage described in sections 3.4 and 3.5; Polar, our payment provider, for the subscriptions in section 3.7; Resend, which sends the sign-in codes, service notices, news and offers in section 3.6 and the circle invitations in section 3.5; and Google Cloud's Model Armor, the screening service in section 3.4. Each acts as our processor, and there are no others. What the connector reads is also passed to the AI client you approved for it, as section 3.4 sets out, and a booking link's or booking page's guest's name and address, and the addresses a poll is for, to the host's Microsoft or Google in the invitation, as section 3.5 does. We may disclose information if required to do so by law.

## 7. International Transfers

Our hosting and analytics provider may process technical data, and our email provider the address it sends to, on servers outside the United Kingdom; the screening service in section 3.4 processes what it is sent in the European Union. Where that happens, it is covered by appropriate safeguards under that provider's terms.

## 8. Data Retention

The public pages leave no personal records tied to you, beyond a poll's answers for the 14 days at most section 3.5 sets out, and aggregate analytics are retained by our analytics provider in anonymized form under their retention terms. What the account and connectors hold is kept while they exist, and sections 3.4 to 3.6 set out what that is.

You can have everything deleted at any time, without asking us: close the account on the connector page, and the deletion is carried out on its own. The Data Deletion page at lumman.co/data-deletion sets out the steps and what they destroy. Two records survive a deletion, and neither names anybody. The first is for each subscription the account held: a one-way digest of that subscription's own identity at our payment provider and the moment the deletion completed, with one line for each notification that provider sent about it. It exists so that a late notification about a deleted account is recognised and refused rather than acted on. Nothing in it can be turned back into you, and all of it is destroyed thirteen months after that moment. The second exists only if you ever gave Lumman access to a Gmail account, and it is written the moment you approve it rather than when a mailbox is connected: a one-way fingerprint of the Google account that authorised it and when it was counted, computed with a key our database never holds. Google's preview gives no place back when an authorisation is withdrawn, so that record outlives the account and is kept for as long as that preview lasts.

## 9. Your Rights

Under UK GDPR you have rights to access, correct, erase, restrict, and object to the processing of your personal data, and to data portability. The public pages collect nothing that identifies you - a booking link's page or a booking page passes what a guest gives into an invitation, and a poll's page keeps the times its invitee picks until the poll is booked or closed or 14 days pass, as section 3.5 sets out - and what an account and its connectors hold is set out in sections 3.4 to 3.6. If you have a question or a request, contact us at in [at] lumman [dot] co and we will help. You also have the right to complain to the Information Commissioner's Office (ico.org.uk).

## 10. Children's Privacy

This website is not directed at children, and its public pages collect no personal information from anyone, including children, beyond the name and address a booking link's or booking page's guest gives and the times a poll's invitee picks (section 3.5).

## 11. Changes to This Policy

We may update this Privacy Policy from time to time. The "Last Updated" date at the top reflects the latest version.

## 12. Contact Us

Questions about this Privacy Policy or our data practices for this website:

- Email: in [at] lumman [dot] co
- Address: Lumman Ltd, 86-90 Paul Street, London, EC2A 4NE, United Kingdom