Privacy

Calendar Agreement is a scheduling tool. An operator publishes one booking link, their customer picks a time on a public page, and a real Google Calendar invite is delivered. This page describes what the product itself does with data.

There are two kinds of people here, and it matters which one you are. An operator signs in with Google and connects their calendar. A customer books a time on an operator’s page and never signs in at all. When you book with an operator, you are dealing with that operator: they decide what to ask you and they can see what you submit. Calendar Agreement stores it on their behalf.

When an operator signs in, we request exactly two Google scopes and no others:

• calendar.app.created ... lets us create one calendar of our own and manage the events we put on it. It does not give access to your other calendars.
• calendar.freebusy ... lets us ask whether you are busy or free during a window of time. The answer is a list of start and end times. It carries no event titles, no guests, no locations, and no descriptions.

A scope we used to ask for, and dropped. Until 27 July 2026 we also requested calendar.calendarlist.readonly, which let us see the names of an operator’s other calendars. Its only use was finding the one calendar we had created. We now remember that calendar’s identifier instead, so we no longer ask for the scope. Two honest caveats: an operator who granted it before that date still has it granted until they remove it in their own Google account, because narrowing what we ask for does not narrow a permission already given; and for those operators we keep reading the list until we have successfully recorded our calendar’s identifier, after which we stop.

The Google Calendar endpoints we call are a free/busy query, creating and checking the one calendar we own, and creating, updating and deleting the events we put on it. We have never called the API that returns your events, and the product is built so that we do not need to.

What we store from Google. Busy periods are cached as start and end times with an empty title field, because a free/busy answer contains no title to store. We keep an identifier for each event we created so we can update or cancel it, and a Google Meet link when the operator enables one. We store a refresh token so we can write to the calendar after you close the browser; it is held in an encrypted secrets store, is never sent to a browser, and is not readable by the application’s ordinary database roles.

Limited Use. Our use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We do not sell Google user data, do not use it for advertising, do not use it to train generalised AI models, and do not let humans read it except where you ask us to, where it is necessary for security or to comply with the law, or where the data has been aggregated and anonymised.

We write to a separate calendar we create, named “Calendar Agreement”. We never write to your primary calendar and we never modify events we did not create.

A booking event carries the operator’s organization name and the service title, the date and time in the operator’s time zone, and a description containing what the customer submitted: their name and email address, their answers to the operator’s intake questions, a service address and description of work if the operator collects those, and a link to the customer’s own booking page.

The customer is added as a guest so the invite reaches them, which means Google emails the invitation, updates and cancellations directly to them. That email comes from Google, not from us. This is deliberate: the calendar is the notification channel, so we do not run a mailing system of our own.

If you book a time, we collect your name and email address, which are required, and your phone number, which is optional. If the operator has set up intake questions we collect your answers to them. Those questions are written by the operator, not by us, so we cannot list here what they might ask ... treat that field as free text going to the person you are booking with. If the operator’s service collects a job address and a description of the work, we collect those too. We also store the date and time you chose and the current state of the booking.

If you are an operator, we collect the name and email address on your Google account, the display name and time zone you set, your booking page address, your weekly working hours, and your cancellation and rescheduling rules. If you signed up after following a link from another operator’s booking page, we record which operator that was, once, so we can tell where sign-ups come from.

We do not collect payment details, we have no advertising or analytics, and we do not build profiles of visitors.

We do not sell your data and we do not share it for advertising. Data is processed by three providers on our behalf:

• Supabase ... the database, sign-in, and the encrypted store holding the Google refresh token.
• Vercel ... hosting and delivery of the website.
• Google ... sign-in, and the calendar the invite is delivered on.

Our codebase contains an unfinished integration with an email provider, Resend. It is switched off and sends nothing. If we ever enable it, we will update this page before we do, not after.

We may also disclose data where the law requires it.

We set cookies for one purpose: keeping an operator signed in. There are no advertising cookies, no analytics cookies, and no third-party trackers. If you only ever book a time, you are not asked to sign in and no sign-in cookie is set for you.

The site loads no third-party scripts, pixels or fonts at runtime. Everything the page needs is served from our own domain.

Booking pages are public, so they are readable without signing in ... but the underlying tables are not. Anonymous visitors cannot read our database directly; they can only call a small, fixed set of operations that return exactly the fields those pages need. A customer’s phone number, address, and intake answers are not returned to the public booking pages.

Your booking link at /meeting/… works without a password, so treat it as private. The identifier in it is 128 bits of cryptographic randomness and cannot be guessed, but anyone you forward that link to can see and change that booking.

No system is perfectly secure, and we would rather say so than imply otherwise. If you find a security problem, please write to privacy@tributarylabs.com.

If you are an operator, there is a button, and it means it. On your booking page, under Delete your account, you can permanently delete your account and everything held under it: every booking including your clients’ names, emails, phone numbers and intake answers; your services, hours and policies; your booking link, which stops working and cannot be reclaimed; the Google token we store; and your sign-in. It happens immediately, there is no grace period, and we keep no copy to restore from.

You can take a copy first. The same screen offers a one-click export of your own record, your booking page settings, your services, and every booking including what clients typed into your intake questions, as a single JSON file. You can do that at any time; you do not have to be deleting anything.

Before deleting anything we remove the Google Calendar events for your upcoming bookings. That is not optional: once the booking record is gone we hold nothing that could ever remove them, so leaving them would strand your clients with a meeting that will not happen. What is your choice is whether Google emails those clients a cancellation. If you say yes, that message carries your organization name and email address so they can follow up with you. If you say no, the meeting still disappears from their calendar but nobody is contacted, which only makes sense if you have already spoken to them yourself.

That removal step is best-effort: if your Google connection has expired or Google is unavailable, we cannot reach those events, and they stay on the calendars they were delivered to. When that happens we tell you exactly which meetings we could not reach, and we log them, so between us they can be cleaned up by hand. Your data is deleted either way ... we do not keep an account alive because a calendar was out of reach.

Cancelling a single booking is a different thing: it marks that booking cancelled, it does not erase it. If you are a customer rather than an operator, you have no account here to delete, and your booking sits inside the record of the operator you booked with. Ask them, or write to privacy@tributarylabs.com and we will action it manually. Depending on where you live you may also have rights to correct, export, or object to our use of your data, and you can use the same address for those.

An operator can disconnect Google at any time from their Google account permissions. That immediately stops us reading or writing your calendar. Note that events we already created stay on the calendars they were delivered to, including your customers’, because they are ordinary calendar entries by then.

This service is not directed at children, and we do not knowingly collect data from anyone under 16. If you believe a child has given us data, write to privacy@tributarylabs.com and we will remove it.

If this policy changes we will update the date at the top. Where a change means we start doing something materially new with your data ... turning on email, for instance, or requesting a new Google scope ... we will update this page before that change goes live.

Questions, deletion requests, and anything else about this policy: privacy@tributarylabs.com.