"The Bridge, Not the Vault." MultiPick Scheduler connects you to services you already own. Your calendar events stay in your own calendar and your address book stays on your own phone — we never take them over. Our server holds only what it needs to run your bookings and to prove what your clients agreed to. Section 11 sets out what it keeps, and how long it keeps it.
MultiPick Scheduler is an appointment booking app for solo professionals and small businesses — personal trainers, tutors, massage therapists, photographers, consultants, and anyone who manages their own schedule. The app lets a business owner select available times, generate a single booking link, and send it to a specific client. The client opens the link, picks one time, and the appointment is set. No marketplace. No directory. One business owner's records are never pooled with another's.
MultiPick Scheduler does not own your appointments and does not hold your business data hostage. It is a tool that sits between you and the things you already use — your calendar account and your phone's own address book — and handles the scheduling. Our server does keep the booking records and consent records your account creates, and Section 11 sets out exactly what those are. But your appointments are real events in your own calendar, so when you stop using the app they stay exactly where they have always been: in your own accounts.
Because your data lives primarily in your own accounts and on your own device, control over it rests with you — not with us. Here is how to delete your data:
Business owners: You can delete your account yourself, from inside the app. Open Settings, tap Delete My Account, and type the confirmation the screen asks for. It runs straight away — there is no request to file and nothing to wait for. If you would rather we did it for you, email us at privacy@multipickapp.com from the address you signed up with and we will process it within 30 days. Either way, deleting your account will:
You can also disconnect the app from your calendar at any time, without deleting your account, by revoking access in your calendar provider's account settings.
Your calendar events remain in your own calendar — we created them on your behalf, but they belong to your account and are not affected by deleting your MultiPick account. You can manage them directly in your calendar app.
Clients: Your booking information goes into the business owner's calendar, and it is also held on our server as part of that business owner's booking records — Section 11 says exactly what those are and how long they stay. We also keep a consent record showing what you agreed to and when (see Section 10). To ask us to delete anything we hold about you, contact us using the email at the bottom of this page with your name and the email address your booking link was sent to. We will process your request within 30 days. If the business owner deletes their MultiPick account, their booking records go with it, and every personal detail is erased from the consent records at the same moment.
If you want your information removed from the business owner's records (their calendar, their device), contact the business owner directly. They hold your record in their own account, and they can delete it. We cannot delete data from their personal accounts on your behalf.
We do not sell your data. We do not sell client appointment data. We do not sell business owner data. We do not share data with advertisers or data brokers. We do not use advertising SDKs or cross-site tracking of any kind.
Data is shared with third-party services only as described in Section 12, and only to the extent those services need it to perform their specific function.
Business owners are professionals who install the app, connect their calendar account, and use it to create and manage appointments. They configure settings, generate booking links, and receive notifications when clients book.
Clients are the people who receive a booking link by email or text and visit a web page to choose a time. Clients do not install the app. They do not create a MultiPick account. They interact only with a single booking web page generated from the business owner's session. Once they book, their interaction with our infrastructure is essentially complete.
Understanding this architecture is the key to understanding our privacy model. Most apps store your data in their own database. MultiPick Scheduler does not. Here is where everything actually lives:
| Data | Where it lives | Who controls it |
|---|---|---|
| Your appointment history | On our server, and cached on your phone so the app is quick to open | You. Deleting your account erases both copies. See Section 11. |
| Your calendar events | In your own Google, Apple, or Outlook calendar | You — in the same calendar app you've always used. |
| Your client contacts | In your own device address book | You — the app looks through it only when you tap Contact on an appointment, to find that client's card. The matching happens on your phone. Nothing from your address book is sent to us. See Section 6. |
| Your settings and themes | On your device, and backed up to our server under your account | You — the backup is what restores your setup on a new phone. Deleted when you delete your account. |
| Booking sessions — the link, the times you offered, and the client's name, email and phone that you typed in when you made the link | On our server | Uploaded when you create the link, before the client opens it. The client's name, email and phone are automatically removed ninety days after the appointment is over (or after the link is cancelled or expires); the rest of the booking record stays until you delete your account. See Section 11. |
| Return-trip booking memory (BUT WAIT round-trip) | Your browser's temporary session storage (per-tab) | A short list of appointments you've already confirmed or canceled during this BUT WAIT round-trip — so when you come back to the page after canceling, you can see what you already handled. Cleared automatically when you close the tab or end the browser session. This is your device, not our server. |
| OAuth tokens (calendar access) | Securely on our server | Used only when you initiate a calendar action. Revocable by you at any time through your calendar provider's settings. |
| Push notification tokens | Not collected | The app does not send push notifications. Booking alerts are delivered by email. |
| Consent records | On our server | Kept as the proof of what a client agreed to. When the business owner deletes their account, every personal detail is erased and only that proof remains. See Section 10. |
If you walked away from MultiPick tomorrow, your working life would carry on. Your appointments are real events in your own calendar, under your own account. We never upload your address book. We are not the place your business lives. But we should be straight with you about the other half: while your account is open, our server does hold your booking records and your consent records, and Section 11 names every one of them.
When you connect your calendar to MultiPick Scheduler, you authorize through your provider's standard OAuth flow. You see exactly what you are authorizing before you approve it. Here is what we request and why:
| Permission | Why we need it |
|---|---|
| Read your calendar events | To check your existing events and show your availability (free/busy information) when you are creating a new booking. We read event times to determine which slots are open — not to inspect the content of unrelated events. |
| Create and edit calendar events | To add a confirmed appointment to your calendar when a client books, and to update or remove it if the appointment changes or cancels. |
Calendar access is the only thing we ask your calendar provider for. We do not request access to your contacts from Google, Apple or Microsoft, and the app never calls a contacts service of theirs.
We do not read your email inbox. We do not access the detailed content of calendar events we did not create — we read event times to determine your availability, nothing more. We request only what the app needs to function — nothing more.
You can revoke calendar access at any time through your calendar provider's account settings. Revocation immediately ends the connection and terminates our ability to read or change your calendar, and we keep no copy of your calendar events after that. Revoking calendar access is not the same as deleting your MultiPick account — your booking records and consent records stay on our server until the account itself is deleted (see Section 2).
Your address book is a separate permission, and it lives on your phone. Your contacts are reached through your phone's own contacts permission, which Android or iOS asks you for directly. The app asks the first time you tap Contact on an appointment. When you do, the app reads your address book on the phone and looks for that client by phone number or email address. If it finds a card, it opens it. If it does not, it opens your phone's own new-contact form with the client's name, phone and email already filled in, and you decide whether to save it. Either way the editing happens in your phone's own contacts app, on your phone. We do not modify, store, or export your contacts, and your address book is never sent to us or stored on our server. You can turn this permission off at any time in your phone's settings — on Android, Settings, then Apps, then MultiPick Scheduler, then Permissions. Turning off Google calendar access does not affect it, because it is not a Google permission.
A client's name, email address and, optionally, phone number are typed in by the business owner when they create the booking link — the client does not fill in a form. The only thing the client does on the booking page is pick a time and tick the consent boxes. That information is used for one purpose: completing and servicing their appointment.
When an appointment is confirmed, the client's email address is added as a guest on the calendar event in the business owner's Google Calendar. Google processes this data under its own privacy policies. No automatic invitation emails are sent by Google — all client notifications come through MultiPick Scheduler.
Once the booking is processed, the client's information sits in the business owner's calendar (their own account, not ours) and in the booking record held on our server for that business owner. Only that business owner's account can see their booking records. We do not build a client database of our own, we never pool one business's clients with another's, and we do not use any of it for anything except running that business's appointments. When the business owner deletes their account, their booking records are deleted with it.
Being straight about what these emails do and do not offer: there is no preference centre and no unsubscribe link in them. The only link at the bottom of an appointment email is Cancel your appointment. To stop text messages, reply STOP to one of them (see Section 13). To stop emails, or to ask us to delete what we hold about you, email privacy@multipickapp.com and a person will handle it.
Before completing a booking, clients are asked to give clear, affirmative consent. We use two separate checkboxes — not one bundled agreement — following the FCC's April 2025 one-to-one consent rules.
Checkbox 1 — Email consent (always shown). This checkbox covers:
This checkbox is required to complete a booking.
Checkbox 2 — SMS consent (shown only when a phone number is provided). This checkbox covers:
This checkbox is optional. Clients can book without checking it — they will simply receive email communications only.
Each consent can be granted or revoked independently. Opting out of SMS does not affect email reminders, and vice versa. Neither checkbox is ever pre-checked — the client must actively check each one.
When a client checks a consent box and taps Book, the app creates a consent record. This protects both the client and the business owner by creating a clear, auditable trail of exactly what was agreed to and when. Here is what a consent record contains:
| Field | What it is |
|---|---|
| Timestamp | The exact date and time consent was given (UTC). |
| Client email | The client's email address, as it was entered on the booking link. |
| Client phone | The client's phone number, if one was entered. |
| Checkbox text (snapshot) | The exact wording of the checkbox the client saw — not a reference, but the literal text. If we later reword a checkbox, old records still show what that specific client agreed to. |
| Privacy policy version | The version identifier of this policy that was in effect at the time of consent. |
| App version | The version of the booking page that was displayed. |
| IP address | The client's IP address at the time of booking. |
| Browser/device info | The browser and device used to complete the booking (user agent string). |
| Consent scope | An explicit list of what was consented to (e.g., appointment booking, email reminders, SMS reminders, age 13+ confirmation). |
| Consent ID | A unique identifier for each consent record, used to reference and retrieve it without ambiguity. |
| Privacy policy URL | A link to the exact version of the privacy policy that was active when you consented, so the full text of that version is always retrievable. |
| Booking page version | The version of the booking page you were viewing when you consented, ensuring the exact interface and wording you saw is documented. |
| Referring page | The web address your browser reported it had come from when it reached the booking page, if it reported one. Your browser sends this by itself; we simply keep what arrives. |
| Business ID | The account ID of the business owner whose booking link you used. This is how the record is tied to their business rather than anyone else's. |
| Series ID and series appointments | On a repeating-series booking only: the ID of that series, and the ID, start time and end time of each appointment you accepted in it. |
| Fields we keep empty | The record also has three slots we do not fill in today: a location, a page fingerprint, and a page language. Every consent record is written with all three left empty. They are named here so this list is complete, and this policy will be updated before any of them starts being filled. |
| Revocation date and method | If you later opt out, the date and method are recorded in the same consent record. Today our system records exactly one method automatically: the SMS STOP keyword. There is no email unsubscribe link; if you ask us by email instead, a person handles it. |
Where consent records are stored: Consent records are held on our Firebase server, in a private area that neither the app nor the public booking pages can read — only our own server code can reach them. They are held there because they are the only proof of what a client agreed to. When a business owner deletes their account, every personal detail is erased from these records — the client's email address, phone number, network (IP) address, browser details and referring page — and what is left contains no client name and no client contact details. To be exact about what does stay: the note still carries the business owner's own account ID, the moment the client ticked the box, and, on a text-message consent, the business name that was written into the checkbox wording the client saw. An ordinary consent note holds no appointment times at all — the only time on it is the moment of the tick. A repeating-series consent is the exception: it also lists the ID and the start and end time of each appointment in that series, so it can still show years later what the client actually agreed to.
How long consent records are kept: Consent records are meant to be kept for 6 years from the booking date, in line with TCPA federal requirements and state consumer protection statutes of limitations. Being straight with you about where that stands today: we have not yet built the automatic clean-up that would delete a record once it passes 6 years, so records are held until something removes them. Two things do. A client can ask us to delete their record using the email at the bottom of this page. And when a business owner deletes their account, every personal detail on their consent records is erased immediately.
Why we capture all of this: If a question ever arises about what a client agreed to, the consent record proves it — down to the exact checkbox wording, the exact time, and the exact version of the policy. This protects clients from being signed up for things they did not agree to, and protects business owners from false claims.
Booking records. When a business owner creates a booking link, they type in the name, email address and phone number of the client they are inviting, along with the time slots they are offering. All of it is uploaded to our server the moment the link is created — before the client has opened it, and before the client has agreed to anything. That is what lets the booking page show the times, and what lets us send the confirmation and put the client on the calendar event. The client does not fill in a form; the only things they do are pick one of the times and tick the consent boxes, and that choice is written onto the same record. This means a client's details sit on our server even if that client never opens the link and never books at all. The appointment record itself — the times, the service, what happened to the booking — stays as part of that business owner's booking history for as long as their account exists, and it is deleted when they delete their account. The client's personal details on it do not stay that long: ninety days after the appointment is over — or, if the booking never happened, ninety days after the link was cancelled or expired — our server automatically removes the client's name, email address and phone number from the record. A booking link that is still open keeps the details it needs to work. The business owner still has the client's details where they have always really lived: in their own calendar and on their own phone. Only that business owner's signed-in account can list these records; a public booking page can only ever read the single booking its own link points at.
OAuth authorization tokens. To perform calendar operations on your behalf, our server stores the authorization token your calendar provider issues when you connect your account. It is held in a server-only area of our database that the app and the public web pages cannot read, it is encrypted at rest by our cloud provider's infrastructure, and it is used only when the app needs to interact with your calendar. You can invalidate it instantly by revoking access in your calendar provider's account settings.
Firebase Auth user records. When a business owner signs into the app, Firebase Authentication creates a lightweight account record containing a unique user ID (UID), email address, display name, and the authentication provider used (e.g., Google). This record exists as long as the account is active and is deleted when the business owner deletes their account.
Business settings and account profile. The settings a business owner chooses in the app are saved to our server under their account, so the setup comes back after a reinstall or on a new phone. That is the whole settings screen, not just the look of it: your business name, address, phone number, email address and website; your booking defaults and reminder choices; your theme and colours; which calendar you picked; and, if you fill them in to register for text messaging, your SMS business details including your tax ID (EIN). Alongside them we keep a small profile record: the user ID; your email address, plus a tidied-up version of it and its domain on their own, which let us tell when the same person or the same company has signed up more than once; your display name and profile photo if the sign-in provider supplied one; the sign-up date and the time of your last sign-in; and the subscription tier. All of it is deleted when the account is deleted.
Sign-up security information. When a business owner creates an account, we record the internet (IP) address and the browser the sign-up came from, and we keep a count of how many sign-ups came from the same address. This is used for one thing only: spotting automated sign-up abuse. It is never used for advertising, profiling, or tracking anyone around the web. The copy stored on the account profile is deleted when the account is deleted. The counts are stored separately. Each one holds the address, the hour it covers, how many sign-ups came from that address in that hour, and the time of the most recent one. It is not linked to any name or email address. Being straight with you about this one as well: those counts were meant to clear themselves after a day, and that automatic clean-up has not been switched on yet. Until it is, the counts stay, and deleting your account does not remove them.
Anti-abuse and operational bookkeeping. Running the bookings leaves a few small technical records behind, and they belong on this list too. When a business owner creates a booking link, the times being offered are written down on our server with that client's name and contact details attached to them, waiting for that client to choose one. That is an offer, not a block. The times are not taken out of circulation while the client is deciding — somebody else can still confirm one of them first, so they stay first-come, first-served until a time is actually picked. Once a client does pick and confirm a time, our server writes down a claim on it, and that claim is what stops a second client confirming the same one afterwards. The appointment itself then lives in the business owner's own calendar, not with us; our claim only keeps one time from being booked twice. A claim is let go when the appointment is cancelled or moved, and all of them are deleted when the account is deleted. When a calendar event is cancelled or replaced, we note that event's ID so a later check does not try to cancel it a second time. When a repeating series is set up or accepted, we note the series ID and the appointment times so the same request cannot be processed twice. These records hold the business owner's own account ID and calendar or appointment identifiers. They hold no client name, email address or phone number. The event and series notes are not deleted with the account — they are there to stop the system doing the same job twice, and they outlive it.
Consent records. As described in Section 10, consent records are held on our server because they are the proof of what a client agreed to. There is no automatic clean-up on them yet. When a business owner deletes their account, every personal detail is erased from their consent records and only the proof that someone agreed is kept.
Push notification tokens. The app does not currently send push notifications and does not collect or store any push notification token. Booking alerts are delivered by email. If push notifications are added in the future, this policy will be updated before that happens.
Those are the categories of data our server holds. No analytics profiles. No advertising identifiers. No cross-site tracking. No pooling of one business owner's records with another's. One timer now runs on our server, and here is exactly what it does: each night it removes the client's name, email address and phone number from booking records more than ninety days past their appointment (or past the link's cancellation or expiry). It removes the client's contact details and nothing else — the appointment record stays, and consent records are not touched by it. Beyond that one timer, nothing else clears itself: booking records and consent records stay for as long as the business owner's account does, because they are that owner's business records and the proof of what was agreed. Deleting the account is what removes them.
We use a small number of established third-party services to operate the app. Each receives only the minimum data needed for its specific function.
| Service | What it does | What data it handles |
|---|---|---|
| Firebase by Google |
Hosts the client-facing booking web pages. Manages business owner authentication (Firebase Auth). Stores booking records, business settings and consent records for the periods set out in Section 11. Runs background functions for reminders, expiration checks, and calendar sync. | Booking records, including the client's name, email and phone that the business owner types in when they create the link. Firebase Auth records (UID, email, display name) and the account profile. Business settings. Consent records. All of it is either deleted or stripped of personal details when a business owner deletes their account. |
| Resend via Amazon SES |
Delivers all transactional emails — booking confirmations, reminders, cancellation notices — from notifications@multipickapp.com, branded with the business owner's name. Resend uses Amazon SES infrastructure for email delivery. | Recipient email address and the appointment details needed to compose the email. Not used for advertising or profiling. Resend may retain delivery logs per their own privacy policy. |
| Twilio Premium Gold only |
Sends appointment-related text messages to clients when the business owner has enabled SMS notifications on a Premium Gold subscription. | Client phone number and the appointment information for the message. Only active when SMS is enabled by the business owner. |
| RevenueCat | Manages Free, Premium, and Premium Gold subscription status through Google Play and the App Store. | App store subscriber ID and subscription status only. No appointment data, calendar data, or booking information. |
| Google reCAPTCHA v3 through Firebase App Check |
Runs invisibly on every booking web page we host — the page a client opens to pick a time, and every page that follows it. Its job is to tell a real browser from an automated script. There is nothing to click and no puzzle to solve, and most people will never know it is there. | While one of those pages is open, Google receives information about the browser and device and how the page is being used, and it keeps rechecking for as long as the page stays open. This happens on every page load, whether or not the client ever books. Google handles that information under its own privacy policy. What comes back to us is only a pass-or-fail answer, not a profile. |
| Google Calendar API Apple Calendar Microsoft Outlook |
Read and write calendar events using the calendar permission you authorize through each provider's OAuth flow. | Only the calendar data you authorize. Your address book is not part of this — it is read on your own phone and never reaches these services through us. Each provider's own privacy policy governs how they handle your data within their platforms. |
| Expo EAS Update |
Delivers over-the-air updates to the business owner's installed app. When the app checks for an update, it contacts Expo's update service. | The device's IP address and technical details about the installed app version, sent only when the app checks for an update. No booking, client, or calendar data is sent. This affects business owners' devices only; clients never interact with it. |
None of these services receive data for advertising. None of them see the full picture of your app — each sees only the narrow slice needed to do their specific job.
MultiPick Scheduler's use of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
SMS text messaging is an optional Premium Gold feature — not active by default. When a business owner with a Premium Gold subscription enables SMS, clients receive appointment-related texts at the phone number they provided when booking — but only if the client checked the separate SMS consent checkbox (see Section 9).
These messages are transactional only: booking confirmation, appointment reminders, and cancellation notices. No marketing messages are ever sent via SMS.
Opting out of SMS. Clients can opt out of SMS at any time by texting any of the following keywords to the number that sent the message:
Opt-out requests are processed within 10 business days. Opting out of SMS does not affect email reminders — email and SMS are independent, and revoking one does not revoke the other.
When you text one of those keywords, we record the date and the method — "SMS STOP keyword" — as part of your consent record. This protects both you and the business owner by creating a clear record that your opt-out was received and processed.
To re-enable SMS after opting out, text START to the same number.
SMS delivery operates under an approved A2P (Application-to-Person) 10DLC campaign registration, meaning our business identity and messaging use case have been reviewed and approved by mobile carriers.
MultiPick Scheduler offers a Free tier and a Premium subscription (Monthly and Yearly plans). All purchases are processed through the Google Play Store or Apple App Store. We never see or store your credit card number, billing address, or any financial information. Payment processing is handled entirely by Google or Apple under their own terms and privacy policies.
Subscription status is communicated to the app through RevenueCat, which verifies your purchase with the app store. RevenueCat receives your app store subscriber ID — not your payment details.
MultiPick Scheduler does not process any payment between a business owner and their clients. Service fees are a matter between the business and their client, handled outside the app entirely. No payment information from either party flows through our infrastructure.
MultiPick Scheduler is intended for users aged 13 and older. Clients confirm they are at least 13 years old as part of the email consent checkbox on the booking page (see Section 9). We do not knowingly collect personal information from children under 13.
All communication between the app, our server, and third-party services uses encrypted HTTPS/TLS connections. All data stored in Firebase/Firestore is encrypted at rest by default as part of Google Cloud infrastructure — this applies to every piece of data our server holds, including OAuth tokens. OAuth tokens are additionally held in a server-only area that neither the app nor our public web pages can read. We never store calendar provider passwords — the OAuth system means your credentials are handled entirely by your provider and never pass through our servers.
Our server infrastructure runs on Firebase (Google Cloud), which holds industry security certifications including SOC 2, SOC 3, and ISO 27001. The business owner's admin interface is authenticated through their own account and is not publicly exposed.
Keeping the pile small is itself a security measure. We do not run analytics profiles, advertising identifiers, or cross-site tracking, and we never pool one business owner's records with another's — so there is less here to lose in the first place. Section 11 names everything our server does hold, and we would rather you read that list than take our word for the size of it.
The following table lists all categories of personal data the app collects or processes. This information supports Google Play Data Safety and Apple App Privacy disclosures.
| Data type | Collected from | Purpose |
|---|---|---|
| Name | Business owners (sign-in). Client names are entered by the business owner when they create a booking link, not by the client. | Account identity, calendar event creation |
| Email address | Business owners (sign-in). Client email addresses are entered by the business owner when they create a booking link, not by the client. | Account identity, transactional emails (confirmations, reminders, cancellations) |
| Phone number | Business owners, when they create a booking link (optional). Clients do not enter their own. | SMS confirmations and reminders (Premium Gold only, with separate consent) |
| Calendar data | Business owners (via OAuth) | Availability display, event creation and management |
| Contacts data | Not collected. The app reads the business owner's device address book on the phone, only when they tap Contact on an appointment. Nothing is sent to us and nothing is stored on our server. | Opening or creating that client's contact card on the owner's own phone |
| Device identifiers (push tokens) | Not collected | The app does not send push notifications |
| IP address | Clients (at booking time), Business owners (at sign-up) | Consent record documentation; spotting automated sign-up abuse |
| Browser/device info (user agent) | Clients (at booking time), Business owners (at sign-up) | Consent record documentation; spotting automated sign-up abuse |
| Business address and tax ID (EIN) | Business owners (optional, typed into the SMS registration settings) | Registering the business to send text messages |
| Browser and device signals for bot checking | Anyone who opens one of our booking web pages, whether or not they book | Sent to Google reCAPTCHA to tell a real browser from an automated script. We receive only a pass-or-fail answer. See Section 12. |
We do not collect device location data, financial information, health data, browsing history, or any data beyond what is listed above.
Applicable privacy laws (including GDPR, CCPA, and others) may give you rights regarding your personal data. Because of how MultiPick Scheduler is built, most of those rights are exercised directly through your own accounts rather than through us:
See Section 22 for contact information.
MultiPick Scheduler is a general-purpose scheduling tool, not a HIPAA-certified medical platform. If your business is subject to HIPAA or other medical privacy laws — such as California's CMIA or Washington's My Health My Data Act — you are responsible for your own compliance. That includes the appointment titles you set, the communication channels you use, and any patient authorizations you obtain. We don't currently offer Business Associate Agreements. If HIPAA applies to you, please evaluate a dedicated healthcare scheduling platform.
If you are a California resident, the California Consumer Privacy Act (CCPA) provides you with specific rights. Here is how MultiPick Scheduler addresses them:
Categories of personal information we collect: Names, email addresses, phone numbers, calendar data (via OAuth), IP addresses, and browser/device information. See Section 17 for the complete list.
Sources: Directly from you when you sign in (business owners). For clients, from the business owner who invites them — the owner types the client's name, email and phone in when creating the booking link. And from your device when it connects to our server (IP address, browser info).
Purposes: Providing the scheduling service, sending transactional communications (confirmations, reminders, cancellations), maintaining consent records, and managing subscriptions. We do not use personal information for advertising, profiling, or any purpose unrelated to the appointment booking service.
Third parties: We share data only with the service providers listed in Section 12 (Firebase, Resend, Twilio, RevenueCat, Google reCAPTCHA, calendar providers), and only the minimum data each needs to perform its function.
Your rights under the CCPA:
To exercise any of these rights, contact us using the email at the bottom of this page. We will verify your identity and respond within 45 days as required by law.
If we make material changes, we will update the effective date at the top of this page and notify business owners through the app before the changes take effect. Continued use of the app after the effective date of a revised policy constitutes acceptance of the updated terms.
Every prior version is publicly archived at its own permanent dated link (for example, /privacy/archive/2026-04-23). Consent records reference the policy version that was active at the time each consent was given, so you can always verify which version of this policy applied to a specific booking.
The current version is always at multipickapp.com/privacy.
For data-related requests (deletion, access, correction, CCPA inquiries):
Email: privacy@multipickapp.com
We aim to respond to all privacy-related inquiries within 30 days.