Lumman

Privacy Policy

Last Updated: 14 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

To offer you the right way to sign in, your browser keeps three 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, and that you have answered the offer to add one. 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 and the approval screen, 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, 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.

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, which is operated for us by Supabase and hosted in London:

  • the credential that mailbox's provider issues for it - or, for an iCloud or Fastmail mailbox, 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 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.

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.

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 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 an iCloud or Fastmail mailbox deletes our copy of its app password; the password itself keeps working until you delete it - at account.apple.com under App-Specific Passwords, or in Fastmail's settings under Privacy & Security. 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, 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, 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. Each address gets its own link, which only an account signed in at that address can use, and it is given to you on the page or to the client that asked. We send the people you invite nothing: you share each link yourself, or that client sends it from your own mailbox. Inviting an address again on the connector page replaces its link; through an AI client its link stands unless the client asks for a new one, which replaces it. Withdrawing an invitation stops its link working. Someone you invite joins by opening their link, 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 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 and a one-way digest of its link - never the link itself - until you withdraw the invitation, delete the circle or delete the account; 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.

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. 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 of our other 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 news email carries a link that stops all such news 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.

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 a Gmail mailbox is refused once that room is gone. While it is, an account can join a list for Gmail: we keep the moment it joined and nothing else, write to the account's own address once, the day Gmail can be added, 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.

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. 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 or a mailbox password is checked; Supabase, which operates the database 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 and news in section 3.6; 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 or to a Google account's calendars, and it is written the moment you approve it rather than when a mailbox or calendar is connected: a one-way fingerprint of the Google account that authorised it and when it was counted, kept apart for Gmail and for calendars and 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