WWaitForMe

Privacy Policy

Last updated 2 October 2026

WaitForMe is a scheduling service operated by Vintechnet. This policy explains what we collect, why we collect it, and what we do with it. It covers waitforme.vintechnet.com and the API at api.waitforme.vintechnet.com.

Who this policy is about

Two kinds of people use WaitForMe. Hosts hold an account and share booking links. Invitees open a host’s link and book a meeting without needing an account. We collect different things from each.

What we collect from hosts

  • Account details — name, email address, username, timezone and an optional short bio. Passwords are stored only as a one-way hash and are never readable by us.
  • Scheduling configuration — your meeting links, available hours, blocked dates, buffers and the questions you add to your booking forms.
  • API tokens you create for integrations, stored as hashes.

Payments and paid features

  • Payments are handled by Stripe. Card details are entered on Stripe’s own pages and never reach our servers. We keep only a Stripe customer reference, which plan you are on, its status and its renewal date.
  • Your own mail server, if you connect one: its address, port, username and password, and the sender address you choose. The password is encrypted at rest and is never shown back to you or anyone else. It is used only to send your own booking emails.
  • Teams: the name of your team, who is in it and their role, and the email addresses of people you invite. Owners and admins of a team can see its members’ upcoming meetings.

What we collect from invitees

  • The name, email address and timezone entered on the booking form.
  • Any guest email addresses added to the invitation.
  • Answers to the custom questions the host has configured.
  • The meeting itself: which link was booked, the start and end time, and any cancellation or reschedule reason given.

This information is collected on behalf of the host who owns the link. They can see it, export it through their API, and receive it at any webhook endpoint they have configured.

Google user data

Connecting Google is optional, and WaitForMe works without it. There are two separate, independent connections a host can make — a Google Calendar, and Google Meet for creating meeting links — and each is consented to on its own. We request only these scopes, and each one exists solely to run a feature the host can see and use in the app:

  • calendar.readonly — to read existing events so the booking page never offers a time that clashes with one.
  • calendar.events — to add a confirmed booking to the calendar, move it when the meeting is rescheduled, and remove it again if the meeting is cancelled.
  • meetings.space.created — to create a Google Meet link for a confirmed booking, when the host has connected Google Meet and chosen it as the meeting location. This scope lets WaitForMe act only on Meet conferences it created itself; it gives no access to a host’s other meetings, and no access to any calendar. It is why a host can get a Meet link for every booking whichever calendar they use, or none at all.
  • openid, email, profile — to identify which Google account was connected, for each connection, and show it in Settings → Calendars, so a host with several accounts knows which one is in use.

We request no other Google scopes, and we use no other Google API data. If a feature ever needs more, we will ask for that access separately and say so here before enabling it.

What we store from Google

We keep a local mirror of your busy times so availability can be calculated quickly. For each event this is the start time, the end time, whether it is an all-day event, its identifier, and its title. We do not store event descriptions, attendee lists, attachments or any other event content. The mirror covers a rolling window of roughly two days behind and four months ahead.

Access and refresh tokens are encrypted at rest. Events marked Free, and events you have declined, are ignored entirely.

From a Google Meet connection we store the connected account’s email address, display name and Google account identifier, so Settings → Calendars can show which account is in use, and the encrypted tokens. For each booking that gets a Meet link we store the link itself and the identifier of the Meet space WaitForMe created for that booking, so the link can be shown to the host and the invitee and reused if the meeting is rescheduled. Nothing else from Meet is stored: no participants, no recordings, no transcripts, no attendance or any other conference content, none of which these permissions give access to.

How Google user data is used

Google user data is used for one purpose only: to provide the user-facing scheduling features described above, which are the features a host connects Google in order to get. In practice that means four things and nothing else:

  • Calculating which times a host is free, so clashing times are not offered.
  • Writing a confirmed booking to the connected calendar, updating it on a reschedule, and removing it on a cancellation.
  • Creating a Google Meet link for a confirmed booking, and giving that link to the host and the invitee so they can join the meeting they arranged. The same link is kept when the meeting is rescheduled.
  • Showing the host which Google account is connected.

What we never do with Google user data

The general How we use what we collect and Who else sees it sections below describe the service as a whole. Google user data is held to the narrower rules in this section, which take precedence wherever the two could differ. We never:

  • sell, rent, license or trade it, to anyone, for any price;
  • use it for advertising, remarketing, personalisation, lead generation, scoring, profiling, or market or product research;
  • use it to develop, improve or train generalised or standalone artificial intelligence or machine learning models;
  • use it for product analytics, usage statistics, benchmarking or any other internal purpose unrelated to running the scheduling features above;
  • send a host’s calendar contents to their webhook endpoints, to a CRM, or to any other third-party destination. Webhook and CRM deliveries carry the booking, invitee and form data created in WaitForMe. Exactly two Google-derived values can appear, both of them created by WaitForMe for that one booking: the identifier of the calendar event we wrote, so the receiving system can match its own record, and the Google Meet link we created, which is the joining address for that meeting and is also sent to the host and invitee by email and in the calendar invitation — it would be useless otherwise. No event a host’s own calendar already contained, and nothing from any other Meet conference, is ever included.
  • use it with any artificial intelligence or machine learning system of ours. WaitForMe sends no Google user data to any AI or LLM service, for any purpose, including to summarise, classify or draft from it.

When Google user data is transferred

Google user data leaves our systems only in these cases:

  • back to Google, to write, update or remove the booking the host asked us to put on their calendar, and to create the Meet link for it;
  • to the host and the invitee of a booking, who are told the Meet link WaitForMe created for their meeting, by email, on the confirmation page and in the calendar invitation, and to that host’s webhook endpoints or CRM as described above;
  • to an API client or AI assistant the host has connected themselves, through our REST API or MCP server, and only on that host’s own instruction. What such a client can see of Google data is the free and busy times used to offer slots, the Meet link for a booking, and which Google accounts and calendars are connected; it cannot read the host’s calendar events, whose titles we store but never expose. A host who connects an assistant is sending their own data to a service of their choosing, under that service’s terms, not ours;
  • to the infrastructure providers that host and back up the service, which process it on our behalf under contract, only as needed to keep the features above running, and for no purpose of their own;
  • with the host’s explicit consent, for a specific purpose they have agreed to;
  • where necessary for security, such as investigating abuse, or where applicable law genuinely requires disclosure;
  • as part of a merger, acquisition or sale of assets, and only after notice to affected hosts and with their consent.

Who can read Google user data

No human at WaitForMe reads a host’s calendar or Meet data except with that host’s explicit consent, where it is necessary for security purposes such as investigating abuse, where applicable law requires it, or where the data has been aggregated and anonymised so it no longer identifies anyone. Administrators can sign in to an account to help with a support request; that is done at the account holder’s request and counts as the explicit consent described here.

Limited Use

WaitForMe’s use and transfer of information received from Google APIs to any other app adheres to the Google API Services User Data Policy, including its Limited Use requirements.

How we use what we collect

  • To work out which times you are genuinely free and show them to invitees.
  • To create, move and cancel bookings, and to place them on a connected calendar.
  • To send the booking notifications and reminders relevant to a meeting.
  • To deliver bookings to the webhook endpoints a host has configured, which sends the booking, invitee and form data to a destination the host controls.
  • To keep the service secure, diagnose faults, and prevent abuse.

We do not sell personal information. We do not use it for advertising or behavioural profiling.

These purposes describe the data a host and their invitees enter into WaitForMe. Data obtained from Google is narrower: it is used only as set out in How Google user data is used above, and is not used for fault diagnosis or analytics — only for security, where that is necessary. No content of a host’s calendar is ever delivered to a webhook; the only Google-derived values that can appear in a delivery are the two described in What we never do with Google user data, both created by WaitForMe for that one booking.

Who else sees it

  • The host of a link sees every booking made through it, including all form answers.
  • Google, when a host has connected a calendar and a booking is written to it. Invitee names and email addresses are included so the calendar invitation reaches them. Also when a host has connected Google Meet, to create the meeting space for a booking.
  • Webhook destinations chosen by the host, which receive the booking, invitee and form data created in WaitForMe and no content from a connected calendar, beyond the two values named above. Once data reaches those systems it is governed by their policies, not this one.
  • An API client or AI assistant the host has connected, through our REST API or MCP server, which can read that host’s own account as they have allowed. Connecting one is the host’s choice, and what it does with the data is governed by its own provider’s terms.
  • Stripe, which processes payments for paid plans.
  • Your own mail provider, if you connect one, which carries your booking emails in place of ours.
  • Infrastructure providers that host the service, under agreements limiting them to processing on our behalf.

We may also disclose information where the law genuinely requires it.

How long we keep it

  • Account and scheduling configuration: while the account is open.
  • Bookings, including invitee details and form answers: retained so hosts have a record of their meetings, until the host or the account deletes them.
  • Mirrored calendar busy times and Google tokens: deleted immediately when a calendar is disconnected, and when the account is deleted.
  • Google Meet connection details and tokens: deleted immediately when Google Meet is disconnected, and when the account is deleted; the access we hold is revoked with Google at the same time. A Meet link already created for a booking stays on that booking, so the host and invitee keep a record of the meeting, and is deleted with it.
  • Webhook delivery logs: a rolling recent history, for troubleshooting.

Your choices

  • Disconnect a calendar at any time from Settings → Calendars. This deletes the stored tokens and the mirrored busy times.
  • Disconnect Google Meet at any time under Video meetings on the same page. This deletes the stored tokens and revokes our access with Google; bookings simply stop getting a Meet link.
  • Revoke access from Google directly at myaccount.google.com/permissions.
  • Cancel a booking using the link in your confirmation, whether or not you hold an account.
  • Request access, correction or deletion of your personal information by writing to ganesan@vintechnet.com. Invitees who want a booking removed should contact the host who owns the link, or write to us and we will help.

Security

Traffic is encrypted in transit. Calendar tokens are encrypted at rest. Passwords are hashed. Webhook payloads are signed so a receiving system can verify they came from us and have not been altered. No system is perfectly secure, and we do not claim otherwise.

Children

WaitForMe is not directed at children and we do not knowingly collect information from them. If you believe a child has provided us with personal information, contact us and we will remove it.

Changes

If this policy changes in a way that materially affects you, we will make the updated version available here and change the date at the top before the change takes effect.

Contact

Questions about this policy, or about your information, can go to ganesan@vintechnet.com.