Privacy notice

Effective date: 2026-10-09

Glideberry provides Calendar Waitlist – Fill Cancellations. Questions or requests about this notice can be sent to support@glideberry.com.

Information used

For an opt-in waitlist request, we use the selected appointment slot (or, for an earlier-time request, the customer’s existing appointment on that calendar), customer name and contact details, consent, timezone, and the business account’s calendar and contact information. We use this information to confirm the request, check whether the selected slot becomes available, and send an approved waitlist message.

On a class calendar, the waitlist works per seat. Calendar Waitlist reads a session’s booked seats from the CRM to see whether a seat is free and whether the customer already holds one, and stores only the seat counts, until the session ends.

Calendar Waitlist stores only the provider contact ID and a masked contact destination for a waitlist entry. Customer verification and offer links are stored as hashes, not as raw links. We do not persist raw contact destinations, message-link tokens, or message bodies.

Scheduling page

A business can turn on a scheduling page for a calendar, which customers open as a link, inside the business’s own website, or from a button there. It shows open times to book and full times to join the waitlist for.

To book an open time, a customer enters a name, an email address and, if the business asks for one, a phone number. Calendar Waitlist sends the name, email address, and timezone to the business’s CRM to find or create the contact, adds the phone number only to a contact it just created, and books the appointment. Calendar Waitlist itself stores only the CRM contact and appointment IDs, the booked time, the booking status, and a hash of the booking’s manage link; it does not store the name, email address, phone number, or form. Calendar Waitlist sends no message about a direct booking; the business’s CRM may send its own confirmation, depending on the business’s settings. Joining the waitlist from the page works as described above, with the same consent and confirmation.

Each booking has a private manage link to change or cancel it until the appointment starts. It is shown to the customer once booked, and Calendar Waitlist stores only its hash. It stops working when the booking is cancelled, when the appointment starts, or when the page is no longer available, including after uninstall.

The page can be shown inside only the websites an administrator lists in Calendar Waitlist. There, it receives that website’s domain and the browser’s timezone, to check the website and show times. The page sets no cookies and uses no browser storage. Calendar Waitlist uses a visitor’s IP address in memory to limit how often pages and forms can be used, and does not store it with any booking or waitlist record.

If the business chooses a Google Font for its page, the visitor’s browser loads that font from Google, which receives the visitor’s IP address. If the business adds a logo, the browser loads it from the web address the business provided. Nothing else on the page loads from another site.

Reports and alerts

Staff can see a report of counts, such as people who joined, offers made, and bookings, read from Calendar Waitlist’s own records. It shows no customer details. Alerts shown in Calendar Waitlist hold only the alert type, calendar, day, count, and delivery status, and are deleted after 90 days.

If an administrator turns on workflow alerts, Calendar Waitlist sends alert counts, calendar names, and dates to a workflow in the business’s own CRM, at the address an administrator saves in Calendar Waitlist. An alert never includes customer information. The saved address is encrypted and is removed on uninstall.

How information is handled

We use the business’s CRM to manage contact and calendar information. Marketplace billing is handled through your CRM. OAuth tokens are encrypted server-side. Access is limited to the installed business account, authorized staff and customers using valid verification or offer links.

Uninstall removes OAuth tokens, staff sessions, and waitlist customer links; scheduling-page manage links stop working. Expired verification requests are terminalized; entry-linked records are deleted under the calendar’s 30-, 90-, or 180-day retention setting, closed waitlist records after 180 days, and sanitized audit events after one year. Scheduling-page booking records are deleted under the same calendar setting, counted from the end of the appointment.

Choices and questions

Waitlist messages require consent and are subject to the business account’s current communication preferences. To ask a question or request help with information associated with Calendar Waitlist, contact support@glideberry.com.