Privacy policy
Last updated September 30, 2026
Mint Bookings is a Shopify app made by Mint Labs ("we", "us"). It lets a merchant sell appointments, classes and rentals as products: customers choose a time on the product page, the time is held while they check out, and the paid order becomes a booking in the merchant's calendar. This policy explains what the app handles about merchants and about the merchant's customers, why, and when it's deleted. For customer data we act as a service provider (processor) to the merchant, who is the controller.
The short version
- Bookings are stored with Shopify IDs only (order, line item, customer, product). We don't store customers' names, email addresses, phone numbers or addresses.
- Names and email addresses are shown to the merchant in the app by fetching them from Shopify at that moment; they aren't saved.
- On the Pro plan the app emails customers about their own booking (confirmation, a reminder 24 hours before, and notices if the merchant moves or cancels it). The address is read from Shopify when the email is sent and isn't stored.
- We never sell or share data, use it for advertising, or combine it across stores. The app sets no cookies and uses no trackers.
Information about merchants
| Information | Why |
|---|---|
| Store domain and a Shopify access token | To receive order notifications, create the checkout rule, list products and look up who booked. |
| Store name, contact email and time zone | Store name and contact email are the sender name and reply-to address of customer emails; the time zone is the default for bookable products. |
| Bookable product settings (duration, places, hours, exceptions, location and instructions text) and staff/resource names and hours | To offer the right times. Staff names are whatever the merchant enters (they appear in emails to customers). |
| Plan and subscription status | Read from Shopify to decide which features apply. Payments are handled entirely by Shopify. |
| A private calendar feed token (Pro, only if the merchant turns the feed on) | So the merchant's calendar app can read their bookings. It can be regenerated or switched off at any time. |
Information about the merchant's customers
| Information | How it's used | Kept |
|---|---|---|
| Bookings: product and variant ID, start and end time, number of places or days, staff/resource, the "Booking start/end" text on the order, order ID and number, line item ID, Shopify customer ID, paid/cancelled status, refunded quantity and which booking emails were sent | To keep capacity exact (no double bookings), show the merchant's calendar, and send the booking emails. | While the app is installed, until the customer's data is erased |
| Holds (a time a shopper picked but hasn't paid for yet): product, variant, time, places, the storefront language, and a keyed one-way hash of the visitor's IP address | To keep the time for the shopper during checkout and to stop one visitor from holding every time. The IP address itself is never stored. | The hash is removed when the hold becomes a booking; unused holds are deleted 7 days after they expire |
| Names and email addresses | Shown to the merchant on the calendar and booking pages, and (Pro) used to address the booking emails. Fetched live from Shopify, or read from the paid-order notification in memory to send the confirmation. | Not stored |
| Order notifications from Shopify (which include personal details such as email and address) | Only IDs, quantities, the booking line properties, the customer's first name and email (for the confirmation email, Pro) are read. Nothing personal is stored or logged. | Not stored |
| Rate-limit keys (keyed one-way hashes of IP addresses) | To stop automated requests to the storefront calendar. | 25 hours |
| Browser storage on the shopper's device | The calendar keeps the shopper's current hold in session storage so it survives a page reload during checkout, and today's date in local storage so it tells us "the calendar is live" at most once a day. No cookies, no tracking. | On the device |
Emails to customers (Pro)
Booking emails are transactional: they're only sent because the customer booked, and only describe that booking. They show the store's name, replies go to the store, and they contain no marketing or tracking. Merchants can switch each type off. We send them with Cloudflare Email Service; message contents and addresses are not logged by the app.
Customer privacy requests
- Access requests (Shopify's
customers/data_request): the app home shows the request and the merchant downloads the customer's bookings as a file to send them. - Erasure requests (
customers/redact): we permanently delete the customer's bookings (by customer ID and the orders Shopify lists). - Store deletion (
shop/redact, sent 48 hours after a merchant uninstalls): we permanently delete everything we hold for the store.
Where data is processed and how it's protected
The app runs on Cloudflare (hosting, database and email sending) and connects to Shopify's APIs. Data is encrypted in transit (TLS) and at rest. Access is limited to Mint Labs staff who need it to provide support. We use no other sub-processors, analytics or trackers. See our security policy.
Retention
Bookings are kept while the app is installed so the merchant's calendar and capacity stay correct, and are deleted when the store is deleted after uninstall (48 hours) or, for one customer, when the merchant or Shopify asks us to erase them. Access tokens are deleted as soon as the app is uninstalled, and the calendar feed link stops working immediately. Unused holds are deleted 7 days after they expire; rate-limit keys after 25 hours.
Your rights
Depending on where you are, you may have the right to access, correct or delete information about you. Merchants can contact us directly; customers should contact the store they booked with, or email us and we'll pass the request on. We respond within 30 days.
Changes
If we change this policy we'll update the date above and, for significant changes, notify merchants in the app.
Contact
Mint Labs — support@stickermint.com