Privacy

Overlap helps a group find a time everyone can make, then puts it in the calendar. This page says exactly what it stores to do that, who can see it, and when it goes away.

The short version

Giving an email address is optional, and if you give one it is used to send you one calendar invitation and for nothing else. Nobody is tracking you here: there is no advertising, no cookies for it, no profile of you, and nothing is sold or shared with anyone. Two third parties do get a request from your browser, and both are named below with exactly what they receive. If you want your data gone before it expires, ask, and it is deleted.

What is stored, and why

The name you type when you say when you are free, and an email address if you choose to give one: The name labels your availability on the grid so the group can see who is free when. The address is optional and is used for one thing: putting you on the calendar invitation once a time is chosen. Leave it blank and your availability still counts — nothing is sent to you, and nothing about you reaches anyone's calendar.
The times you paint on the grid: This is the entire point of the product. It is visible to anyone holding the event link, which is how a shared grid works.
The event's title, dates and timezone: Typed by the organiser. The title becomes the calendar event's name, so everyone invited sees it.
Two cookies: One marks this browser as the event's organiser. One remembers which response on the grid is yours, so a reload shows your answer instead of an empty form. Neither is used for advertising or shared with anyone.
A one-way hash of the Google account that books a meeting: Used only to count how many invitations that account has sent today, so one person cannot use the service to mail strangers at scale. The address itself is not stored in this counter and cannot be recovered from it.
The organiser's email address, if they ask to be notified: Optional, and asked for only when creating an event. It is used for at most two messages about that one event — when everyone has answered, and a progress note a day later — and for nothing else. It is never used to reach anyone about a different event, never added to a mailing list, and the messages never contain the organiser's private link. It is deleted with the event.
Email delivery, by Resend (resend.com): The service that actually sends the two organiser messages above, and the only one of these that receives an address. It sees the recipient, the subject and the text of a message it is asked to deliver. Nothing is sent to it unless an organiser asked to be notified.
Anonymous page-view counts, from Vercel Web Analytics: How many people opened a page, which page, roughly where in the world, and on what kind of device. It sets no cookie and creates no identifier that follows you between sites, so it cannot tell that two visits were the same person on different days. Event links are stripped before anything is sent: a visit to your event is recorded as /e/[slug], never the link itself, because that link is what protects the event.
A bug-reporting script from Jam (jam.dev), on the public pages only: It loads on the home page, this page, the terms page, and the demo grid. It does not load on an event page, so it is never present where names, availability, or email addresses are on screen. Where it does load, it sits idle unless someone deliberately files a bug report; when they do, it sends that person's recording of their own screen along with the browser console and network activity from the page they were on. Nobody else's session is recorded, and nothing is sent unless a report is filed.

Who can see it

Anyone holding the event link. That is how a shared availability grid works, and it is worth being plain about: the link is the only thing protecting an event. Names, availability and the event title are visible to whoever has it. Email addresses are not shown on the grid.

Deciding the time and booking it is restricted to the organiser (the person who created the event), and that is enforced on the server, not just hidden in the interface.

Google Calendar

When the organiser books the meeting, they sign in with Google. Overlap asks for the narrowest permission that can do the job: calendar.events.owned, which allows creating and changing events on calendars that account owns. It cannot read the organiser's existing calendar, and it is never used to look at anything.

The access token is used within seconds to create one event, and is then discarded. No long-lived token is requested and none is stored, so Overlap has no standing access to anyone's calendar. Revoking it at your Google account permissions is possible at any time and costs nothing, because there is nothing ongoing to revoke.

Creating that event sends a calendar invitation to everyone who put their address on the grid. That is the feature. It also means an invitation can arrive from someone you know rather than from Overlap, because the meeting lives on the organiser’s calendar, under their account.

Who Google user data is shared with

Signing in with Google gives Overlap the address of that account and Google’s own identifier for it, which calendar to write to, and — once the meeting exists — that event’s identifier, its link and its Meet URL. That is the whole of the Google user data Overlap ever holds.

It is disclosed to these parties and no others:

Google: The meeting’s title, time and guest list are sent to the Google Calendar API to create the event. This is the purpose the permission is asked for.
The people invited to the meeting: Creating the event puts the organiser’s name and account address in front of everyone invited, in their own calendar. That is what an invitation is, and it is worth stating plainly rather than leaving it to be inferred.
Vercel: Hosts the application, so every request passes through their infrastructure. Overlap runs in their Dublin region.
Supabase: The database. The record above — account address, Google identifier, calendar and event identifiers, links — is stored there, in their EU (Ireland) region, and deleted with the event.

Vercel and Supabase are service providers processing this data on Overlap’s behalf to run the product. They are not permitted to use it for anything else.

It is never sold, and never shared with advertisers or data brokers. It is not used to develop, improve or train any artificial-intelligence or machine-learning model, generalised or otherwise. Resend, which sends the optional organiser notifications, never receives any of it: those two messages contain the event title, how many people have answered, their display names and the public event link, and nothing that came from Google.

How it is protected

In transit. Everything is served over HTTPS. The site sends HSTS for a year including subdomains, so a browser that has visited once will refuse to talk to it over plain HTTP at all.

At rest. Stored in Postgres at Supabase, encrypted at rest on their infrastructure.

Who can reach the database. Nobody, from the outside. Row-level security is switched on for every table with no policy granting access, so the public API key can read nothing at all; the application reaches the data with a server-side credential that never leaves the server. Access to the account itself is limited to the person who runs Overlap.

What is never written down in the first place. This is the protection that matters most, because data that does not exist cannot leak:

No refresh token. Access is requested as online-only, used within seconds and discarded, so there is no stored credential that could be taken and reused.
The organiser’s private link is kept only as a one-way SHA-256 hash. Someone with the entire database cannot reconstruct it.
The Google address behind the abuse counters is kept only as a one-way hash, so those counters cannot be read back to say who booked what.

In the browser. The organiser’s capability travels in a URL for two redirects before it is exchanged, so the site sends a referrer policy that stops that URL reaching any other site. The site also refuses to be displayed inside a frame, which is what a clickjacking attempt on the booking button would need.

How long it is kept

An event and everything attached to it (names, addresses, availability) is deleted automatically 365 days after it is created. There is no archive. The invitation-counting hashes are kept for the same period.

A meeting already created in Google Calendar is not affected by any of this. It belongs to the organiser's Google account, and deleting it is done there.

What is deliberately not stored

No accounts and no passwords. Participants never sign up.
No long-lived Google credentials, as above. Nothing that would let Overlap touch a calendar tomorrow.
The organiser’s private link is stored only as a one-way hash, so even someone with full access to the database cannot reconstruct it and take over an event.
No advertising identifiers, no cross-site tracking, no data sales.

Who else your browser contacts

None of these can see an event’s contents, and none of them receive anything that came from Google:

Vercel Web Analytics: Counts page views by route, referrer, country and device type. No cookies and no identifier that follows you between sites. Event links are redacted in the browser before anything is sent, so the part of the address that identifies your event never leaves the page.
Buy Me a Coffee: The support badge in the corner is an image served from their CDN, so loading a page tells them your IP address and which page you were on. Nothing else is sent, and nothing is sent at all about the event itself. Visiting their site only happens if you click it.
Jam: A bug-reporting script, on the public pages only — the home page, this page, the terms page and the demo grid. It does not load on an event page, so it is never present where names, availability or email addresses are on screen. Where it does load it sits idle unless somebody deliberately files a bug report; filing one sends that person’s own screen recording along with the browser console and network activity from the page they were on. Nobody else’s session is recorded, and nothing is sent unless a report is filed.

Getting your data removed

Email overlap-support@googlegroups.com with the event link, and the event and its responses are deleted. No account or verification is required, because there is no account to verify against, which also means anyone with the link can ask, and that is a deliberate trade for not making people sign up.

Terms · Home