Privacy policy

In short

• Mighty plans trips with AI. Your conversations and trips are stored with your account and sent to AI providers (Anthropic, with Google Gemini and Groq as backups) to get an answer. When an answer depends on something current (events on your dates, whether a place is open), the model can search the web: it writes the search words itself, and the search goes through Anthropic or Google, with nothing that identifies you.
• You can use it without giving a name or email address. Signing in is your choice.
• We do not sell personal information and we show no ads. We earn a commission when you book through some links, and we measure our ads on Facebook and Instagram with the Meta pixel, only if you agreed to it.
• Searches with flight, hotel and tour providers go out from our server without anything that identifies you. Some content (maps, images, fonts and the flight search engine) loads in your browser straight from third parties.
• You can delete a trip, or your whole account, yourself on the site. For everything else, write to hello@mightyholiday.com.

Your account

The first time you use the app or the site, we create an anonymous account for you through Google Firebase Authentication. It is a random identifier, with no name, email address, phone number or password attached. You can keep using Mighty this way for as long as you like.

On the site you can choose to sign in, with Google, with a code sent to your email, or with an email address and password. The reason to do it is to keep your trips: an anonymous account's trips are stored on our servers too, but only this browser holds the key to them. Signing in ties them to an account you can open from any browser or device.

If you sign in with Google, you do it in Google's own window, and Google passes your name, email address and profile photo to Firebase Authentication, which keeps them as part of the account. The site shows your name (or your email address, when there is no name) and your profile photo in the studio menu, and your name, photo and email address on your account page. Your browser loads the Google profile photo straight from Google's servers, not through us.

If you sign in with an email address and password, Firebase Authentication keeps your email address. You type the password into our page, but your browser sends it straight to Firebase Authentication. It never reaches our servers and we cannot see it.

If you sign in with a code, you type an email address and we send a 6-digit code to it through Resend (see "Who else processes your data"). For the ten minutes the code is valid we keep only a scrambled version (hash) of the code and of the address in Firestore, with when it was sent and the number of attempts, and we delete it once the right code is entered. After that the address is kept as part of the account in Firebase Authentication, marked as verified. A new account opened this way also gets a random password in Firebase Authentication that nobody knows and that is not stored anywhere, because Firebase needs at least one sign-in method to treat an account as signed in.

When a new account is opened with a verified email address (Google or a code), we send it one welcome email through Resend. So we never send it twice, the account records when it was sent.

Reminders about a trip you didn't finish: if you started planning a trip while signed in and stopped before the full plan, a few hours later (in the daytime) we send one email through Resend to the verified address on your account, with the destination, the dates and a link back to the chat. At most one reminder per trip, and at most one every three days per account. So we don't send it again, the trip and the account record when it was sent. You can stop them any time with the switch on your account page or the link in every such email, and then the account records that you asked to stop.

On your account page, and in the first step of the "My preferences" screen, you can change the name that is shown. The new name is kept by Firebase Authentication in place of the name that came from Google.

You can also upload a photo of your own there, to show instead of your Google photo. Your browser shrinks it to a 256 by 256 pixel square (60KB at most) before sending it, and our server keeps it in Google Firebase's Firestore database, in a record identified only by the account's random identifier. Only your account can fetch it back, and it is shown only to you. The Google photo itself stays with Firebase Authentication. The "Restore Google photo" button ("Remove photo" on an account with no Google photo) deletes the photo you uploaded from our database straight away, and deleting your account, as described below, deletes it too.

If you signed in with Google, you can add a password on your account page so you can also sign in with your Google account's email address and a password. It is the same account with the same trips. Firebase Authentication may ask you to sign in with Google again first. The password is handled like any other password here: your browser sends it straight to Firebase Authentication, it never reaches our servers and we cannot see it.

Your name and email address stay with Firebase Authentication. We do not copy them into the database where your trips are kept, and our servers identify you only by the account's random identifier. The only part of your profile we keep is a photo you uploaded yourself.

What signing in does to your data

If the Google account or email address is new to us, your anonymous account simply becomes the signed-in account. It keeps the same identifier, and nothing moves.

If you have signed in with it before, for example in another browser, you are signed in to that existing account, and our server moves what this browser's anonymous account holds into it: your trips, saved places, preferences and daily usage counters. The server does this only when the same browser proves it holds both accounts, and only from an anonymous account into a signed-in one.

Saved places from both accounts are combined without duplicates. Where both accounts have the same preference set, the signed-in account's choice is kept. Usage counters are added together, so signing in does not reset a daily limit. Shared links to the trips that moved keep working. If a trip clashes with one already in the account, the one in the account is left untouched and the anonymous account's trip is added beside it as a separate trip. Once everything has moved, the emptied anonymous account is deleted. If anything could not be moved, the anonymous account is kept along with it.

The usage event records described below are not moved. They stay under the old anonymous identifier.

If the move fails, you stay signed in and nothing is deleted. The site offers to try again until you reload or close the page. If the page is closed first, those trips stay on the old anonymous account.

Signing out

Signing out deletes nothing on our side. Your trips, saved places and preferences stay in the account and come back when you sign in again, in this browser or any other.

In this browser, signing out removes the local copy of your trips, your saved places and your "My preferences" answers, and the note of which trip was open, then starts a new anonymous account with a new identifier and no trips. Other things this browser remembers by itself are not cleared when you sign out, such as your language, the panel layout, flight and hotel preferences, the place photo cache, your booked and packed ticks and the note that the welcome screen was already shown to that account. Clearing your browser data removes them.

What we store about you

• Your conversations with Mighty and the itineraries it writes, kept with your account so your trips are there next time. This includes what was extracted from a file or link you added with the + button, because it becomes part of the message you send.
• The trip details you choose: destination, dates, number of travellers, budget level, flight and accommodation preferences, and the flights, hotels and tours you picked or marked. On a trip within Israel we ask once whether you have your own car or will rent one, and keep the answer with your account and in your browser, so that later trips within Israel offer a rental car only to those who need one.
• Your preferences for future trips ("My preferences"), only for a signed-in account and only if you fill them in. After your first sign-in we show a short welcome screen once, and every question on it can be skipped: the city or airport you leave from, who you usually travel with (solo, as a couple, as a family or with friends, and for a family the number of adults, the number of children and the children's ages if you give them), your travel style, your usual budget level and whether to include TikTok and Instagram trends. We also store whether you finished or skipped that screen, so it is not shown again. These preferences are kept with your account, used as the default departure city and group in the trip bar and the flight search when a trip has no value of its own, and sent with the first message of every new trip to the AI provider that writes the answer, as described below. You can change them at any time under "My preferences" in the menu and on your account page.
• Places you save, and what you have ticked as booked or packed.
• Packing lists you asked for, stored per account, trip and language.
• Your language choice.
• Individual usage events. When you tap a booking link, a place's website, a trends video, or tick something as booked, we store a separate record of that event containing your account's random identifier, the time, the type of action, the partner, the place, the city and the trip it belonged to. We also keep a daily count per partner. We use this to see which features are worth keeping. It is never sold and is not used for advertising.
• Daily usage counters for your account (how many messages, searches and imports today), to enforce limits and prevent abuse.
• A technical log of AI requests in the chat. For each chat answer we store a line with the time, the trip identifier, the language, the stage of the conversation, the model that answered, the token count, the response time and the cost. The line contains no text you wrote. We use it to track cost and to fix problems. Only the operator can see this log, in an admin page protected by a secret key.
• Flight and trip notification details, if you allowed them in the app, as described under Expo below.
• WhatsApp conversations, if you write to Mighty on WhatsApp, as described under Twilio and WhatsApp below.

What not to type into the chat

Please do not type into the chat, or upload with the + button, passport numbers, card details, health information or other sensitive details, including other people's. Mighty does not need them to plan a trip, and everything you write is stored with the trip and sent to Anthropic, or to a backup provider (Google Gemini, or Groq if Gemini is unavailable too) when Anthropic is unavailable, to get an answer. If you already have, delete that trip (or your whole account), which removes it from our servers too. The technical log described above keeps no text you wrote.

Cookies and storage on your device

The app stores your trips, saved places, your language, your ticks and a cache of place photos on the device itself, so it works offline and loads quickly. The site keeps the same kind of state in your browser's local storage, and Firebase keeps your sign-in state there. Clearing the app's storage or your browser data removes them.

Our cookies, all needed for the site to work: mh-lang, which remembers the site language for a year; three one-day cookies (mh_geo_airport, mh_geo_country, mh_geo_place) holding the airport, country and city nearest to you (see "Language and departure airport by location"); and mh-consent, which remembers your choice in the cookie banner for 12 months (with a copy of the same name in your browser's local storage), with no identifier in it. Vercel Web Analytics and Speed Insights, which the site uses to count visits and measure speed, work without cookies according to the provider. The only advertising cookies are the Meta pixel's (_fbp, and _fbc when you arrive from an ad), set only after consent, as described below.

Where you came from: when your first visit comes from a link with a campaign tag (for example a link in one of our reels) or from another site (for example a search engine or a social network), your browser keeps only the name of that source in local storage (mh.src, for example instagram/reel/rome), and, when the link came from an ad, the ad's name in it (utm_content), and we keep them with your account after your first action in the planner, and with the time you signed up and the time of your first full plan. The name says which channel you came through, not who you are, and no cookie is set for it. We use it to count how many people came from each channel, how many of them planned a trip and how many tapped booking links, so we know what is worth spending money on. The same name is also added to our booking links at the partners (a sub-id), so their reports show which channel a booking came from. Clearing your browser data removes it from the browser, and deleting your account removes it from us.

On your first visit a small banner appears at the bottom of the page: "Necessary only", "Accept all" or "Settings", which has one switch for analytics and third-party widgets. You can change your choice at any time with the "Cookie settings" link at the bottom of the site. Withdrawing consent deletes the Travelpayouts cookies described here.

The flight search screen in the app is Travelpayouts' own search engine, embedded in our pages (the website no longer loads it). It loads only if you accepted third-party widgets, or if you tap "Load flight search", shown in its place, which is consent for that widget alone. Once loaded it writes cookies of its own on our domain: two whose names begin with _sp_id. and _sp_ses., an analytics visitor identifier kept for 400 days and a half-hour session marker, tpwl_locale and tpwl_currency for a year, which remember the language and currency you chose in that form, and hide_hotels, written only if you untick "show hotels" and removed when you tick it again. It also keeps a queue of analytics events waiting to be sent and a cached currency table in your browser's local storage. This is written only on the screen where that search appears, and clearing your browser data removes all of it.

The Meta pixel (Facebook and Instagram): we advertise MightyHoliday with ads on Facebook and Instagram, and to know whether they work the site can load the Meta pixel from connect.facebook.net. It loads only if you chose "Accept all" or turned on the analytics and third-party switch. Once loaded it reports to Meta each page you open (PageView), a new waitlist signup (Lead), a tap that leaves for a booking or ticket site (InitiateCheckout), the first full plan of each trip (PlanCreated), your very first full plan (StartTrial) and opening an account (CompleteRegistration), without your email address, the destination or anything else you entered. The last two are also sent by our server straight to Meta (the Conversions API), only if you gave the same consent, with the same event number, so Meta counts each once even when the browser blocks the pixel. A server report carries the event's name and time, the page address, the IP address and browser type of the request, the _fbp and _fbc cookies if present, and your account number with us after one-way scrambling (SHA-256), which does not reveal the number itself, with no email and no name. With each report Meta receives what any normal page load carries (your IP address, browser type, the page address and the page you came from), and it keeps a cookie named _fbp on our domain, a browser identifier for 90 days, and _fbc, only when you arrived by clicking an ad. Meta uses this to measure and target our ads, and if you are signed in to Facebook or Instagram in the same browser it may link it to your account there, under its own policy. How to stop it: use the "Cookie settings" link at the bottom of the site and choose "Necessary only"; the _fbp and _fbc cookies are then deleted and the pixel no longer loads. You can also manage the ads you see and Meta's use of activity from other websites in the ad settings of your Facebook or Instagram account (Accounts Center, https://accountscenter.facebook.com/ads).

The videos screen in the studio plays each video in the official player of the network that published it (TikTok, YouTube through youtube-nocookie.com, or Instagram). A player loads only if you accepted third-party widgets, or if you tap "Play the videos" on that screen, which is consent for those players until the end of your visit only. Only the video on the screen is loaded. The player loads from that company's servers, which receive your IP address and may set cookies of their own under their domain and under their own policy. We receive nothing about you from it.

When you tap an affiliate link and go to a provider's site, the provider or the affiliate network may set cookies of their own on their site, to credit a booking to us. That happens on their side and under their policy.

Language and departure airport by location

On the site, the page language is chosen from the country our host (Vercel) infers from your IP address, and your choice is then kept for a year in a cookie named mh-lang. You can switch language at any time and the cookie follows. From the same Vercel information (country, city, approximate coordinates and time zone inferred from your IP) we also pick your nearest airport as the default departure, the default currency and today's date; the airport, country and city are kept for one day in the cookies mh_geo_airport, mh_geo_country and mh_geo_place, and the coordinates are not stored. An airport you chose in "My preferences" always wins. Separately, Travelpayouts' flight search engine, which works out your location from your IP address by itself, as described below. The app uses your device's language setting instead, and does not use your IP for this. To prevent abuse of the flight and hotel searches (which cost us money), each such search is also counted for one day by device and by connection: your browser sends a code computed from general device characteristics (browser and system type, languages, screen size, time zone and number of processor cores), and for visitors who are not signed in, the IP address is taken into account as well. We store neither the address nor that code itself, only a one-way code computed from them together with the date, so the address cannot be recovered from it and different days cannot be linked, and after the day it is no longer used. When your device's time zone is far from your address's time zone (for example on a VPN), or the browser is automated, the daily number of searches is lower, and we may ask for a short Cloudflare check (Turnstile) to confirm you are not a robot. The check loads from challenges.cloudflare.com only in that case, and Cloudflare receives from it what any normal page load carries (your IP address, browser type) and the browser signals the check needs. Passing it sets a cookie named mh_human for one day, containing only a code that confirms the pass on this device. https://www.cloudflare.com/privacypolicy/

Who else processes your data

• Google Firebase stores your account, including the name, email address and profile photo of a signed-in account, and your trips, saved places, "My preferences" answers, any profile photo you uploaded and the rest of what is described under "What we store about you".
• UserWay The accessibility button on the site (larger text, contrast and more). Its script loads from cdn.userway.org, so UserWay receives what any normal page load carries (IP address, browser type, the page) and stores the accessibility settings you choose in your browser. It loads before any choice in the cookie banner, because it is part of the site's accessibility, not a tracking or advertising tool. https://userway.org/privacy/
• Resend An email delivery service. It receives your email address and the content of the email when we send a sign-in code, a welcome email for a new account, a reminder about a trip you didn't finish, or a waitlist confirmation. https://resend.com/legal/privacy-policy
• Anthropic receives the text of your conversation, your trip details and your "My preferences" answers (not your name) so that Mighty can answer, and, when it is available, the same place and trip details described under Google Gemini below. Under Anthropic's commercial terms, data sent through its API is not used to train its models.
• Google Gemini when Anthropic is unavailable, Google's Gemini API writes the answer instead (through one of our two Google accounts), and Google then receives what would have gone to Anthropic: the text of your conversation, your trip details and your "My preferences" answers; a place's name, city and details about it from Google Maps, to write a place overview; a place's public Google reviews, to write a review summary; a place's name, city and type, and for the personal tip also what is known about the travellers, to write a booking guide; the destination, dates, travellers and stop names, to make a packing list; the destinations, dates, group and budget of your past trips, to suggest new destinations; tour titles, to translate them; and the destination name, as a Google Search query, with the titles, captions and creators of the trending videos found. We use the Gemini API on its free tier, and under Google's terms Google may use this content, including through human review, to improve its services.
• Groq a backup AI provider that runs open models (such as Llama and gpt-oss) on its own servers. When both Anthropic and Google Gemini are unavailable, a model running on Groq writes the answer instead, and Groq then receives what would have gone to Gemini, except the Google Search query: the text of your conversation, your trip details and your "My preferences" answers; a place's details and reviews, to write a place overview, a review summary and a booking guide, and for the personal tip also what is known about the travellers; your trip details, to make a packing list; your past trips, to suggest new destinations; and the titles, captions and creators of the trending videos found.
• Files and links you add in the chat when you add a photo, screenshot, PDF, link or booking confirmation with the + button, our server sends the file, the text read from the link (and the post's cover image) or the text you pasted to Google Gemini for automatic reading (text may also be read by Groq, like the rest of the chat). The file travels encrypted and is not stored by us: it is dropped from our server's memory right after reading. So that a picture you shared shows in the chat, a small copy of it is kept only in your browser (local storage, the last 40 pictures) and is never sent to us. We keep only the trip details extracted from it: the places, and from a booking confirmation the flight number, airports and times, or the hotel name, city and dates. Booking codes (PNR), confirmation numbers and passenger names are removed and not stored; in pasted text they are removed before it is sent for reading. We currently use the Gemini API on its free tier, where Google may use submitted content, including through human review, to improve its products, so don't upload documents you don't want shared. Links are opened by our server, not your device (for TikTok, YouTube and Pinterest through their public oEmbed service), with nothing that identifies you, and the result is served from a shared cache per link for up to 7 days. For a YouTube, TikTok or Instagram video link, the video itself (picture and sound) is also analysed by Google Gemini to find places shown or said in it: a YouTube video is passed to Gemini by its public address, and a TikTok or Instagram video is fetched through Bright Data, downloaded to our server only for the time it takes to read it, and not stored. In both cases only the link and the video are sent, with nothing about you. Our server does not open Instagram or Facebook pages: for those we ask you to paste the caption instead.
• Postmark When you forward a booking confirmation e-mail to trips@mightyholiday.com, it reaches us through Postmark (ActiveCampaign). Our server matches you by the sender's address, reads the confirmation like the + button does (with the same AI providers), and keeps only the booking details until you accept or dismiss it in the chat, for at most 30 days. The e-mail's body, subject and files are not stored by us. Postmark keeps the incoming e-mail for a limited time under its own retention settings.
• Travelpayouts and Aviasales our server asks Travelpayouts for flight prices, with only the airports and dates, and asks it to turn a link (for example the eSIM page for the countries in your trip) into an affiliate link. Hotellook, a former Travelpayouts service, still receives the city and dates in some hotel price checks, although it no longer answers. Nothing that identifies you is sent. On the website, the flight booking button opens Google Flights, with no affiliate code and nothing about you. In the app, a purchase through the flight search screen goes to Aviasales with our affiliate code. Links for attractions, car rental and eSIM go through the Travelpayouts network. They receive something only when you tap, and then what any normal web link carries (such as your IP address). We may earn a commission at no extra cost to you.
• SerpApi, Bright Data and Google when you search for a place to stay or for flights, our server sends a search to Google Hotels or Google Flights through SerpApi, or through Bright Data when SerpApi is unavailable. Only the city or the route (airport codes), the dates and the number of travellers (adults, children and infants) are sent, plus the site language and currency. Nothing that identifies you is sent, and the request goes from our server, not from your browser. We keep the results in a shared cache for up to six hours for hotels and flights. Hotel photos and the airline logo on a flight card are loaded by your browser straight from Google's servers, which receive your IP address. When a flight's details show the "book directly with a seller" option and you open it, our server asks through SerpApi who sells those flights; choosing one of the sellers sends your browser to Google, which passes you on to the seller's site. These are not affiliate links. To find a hotel's page on Booking.com, our server first asks Booking.com's own search suggestions, and if they don't name the hotel clearly, sends an ordinary Google search through Bright Data; both contain only the hotel's name and city. The result, the page address alone, is kept for up to 30 days. In the same way, with an ordinary Google search through Bright Data carrying only the hotel's or place's name and the city, our server finds the hotel's page on Expedia and Hotels.com and the place's or city's page on GetYourGuide, so the buttons can open it directly. Through SerpApi our server also fetches a hotel's reviews and photos when you open its details, and a list of public short videos (TikTok, Reels and Shorts) about your destination. Those requests carry only the hotel's Google identifier, or the city name with fixed search terms, plus the site language. We keep the results in a shared cache for up to 7 days for reviews, photos and videos. Video cover images are loaded by your browser straight from the server that hosts them, and opening a video takes you to the network that published it. When you add a TikTok video link in the chat, our server sends Bright Data only that link, and gets back the video file, its description and its subtitles.
• AeroDataBox when flight status (gate, terminal and delays) is checked for your trip reminders, our server sends AeroDataBox (directly or through RapidAPI) only the flight number and the departure date. Nothing that identifies you is sent, and the request comes from our server, not from your device. The answer is kept in a cache shared by all users for 24 hours at most.
• Expo if you allow flight and trip notifications in the app, we keep your device's notification token, your account's random identifier, your language, the identifiers of the trips you asked to be notified about and, for each flight in your trips, the flight number, date and departure time, plus which notifications were already sent (so none is sent twice), until you turn the notifications off or the device stops accepting them. To suggest trip notifications (for example rain tomorrow at a place in your plan), the server reads the trip's saved plan and the weather forecast for the city. Notifications are sent through Expo's push service, which receives the device token, the notification text (flight number, gate, terminal or time, or the city and a place from your plan) and the trip's identifier, and hands them to Apple or Google for delivery to your device.
• Twilio and WhatsApp if you write to Mighty on WhatsApp, your messages pass through WhatsApp (Meta), which delivers them to our server and sends the replies: either directly, through Meta's WhatsApp Cloud API, or through Twilio, a provider that connects us to WhatsApp. Meta, and Twilio when it is in the path, receive your phone number, your WhatsApp profile name and the text of the messages and the replies, and keep them under their own settings and terms. The conversation's text is sent to the AI providers as in the chat on the site (Anthropic, and Google Gemini or Groq when it is unavailable). On our side the conversation is stored under a code computed from your phone number, not under the number itself: up to the last 12 messages from you and Mighty, the language, the identifiers Meta or Twilio gave the last messages (so none is answered twice), and a daily message counter for the quota, so we can pick up where we left off. We do not store your profile name, and we do not read photos or files sent there. If you ask to talk to a person (for example "representative"), we separately keep your phone number, so someone from our team can answer you from the same WhatsApp number, the conversation from then on (up to 200 messages), including the messages before the request, and a short summary of it written by the AI provider. The team sees these on an internal screen and is alerted about the request. While someone from the team is answering you, Mighty does not. Write "reset" to delete the stored messages (and any request for a person), or "stop" and we will send you no more messages ("start" brings you back). A conversation nobody wrote in for 30 days is deleted entirely and automatically, and so is a request for a person 30 days after its last message.
• CJ the Booking.com booking buttons (the hotel's page, or a Booking.com search when we have not found the page) go through CJ (Commission Junction), an affiliate network, on their way to Booking.com. The link carries the page address, the dates, the number of adults and children (and the children's ages when you gave them) and our affiliate code, and nothing that identifies you. CJ receives it only when you tap, along with what any normal web link carries (such as your IP address), and passes you on to Booking.com. We may earn a commission at no extra cost to you.
• Viator when you ask for tours, food experiences or tickets, or when we check whether a place in your itinerary has a tickets page, our server sends Viator the city and what is being searched for (the place's name, or the kind of tour), plus the trip dates and the currency. Nothing that identifies you is sent, and the request comes from our server, not from your device. The answer is kept in a cache shared by all users for one hour at most, and the match between a place and its Viator page for a week at most. Tour photos are loaded by your browser directly from Viator's servers. In Hebrew, the tour titles (and nothing of yours) are sent to the AI provider that translates them. The booking button takes you to Viator with our affiliate code and a random trip code that does not identify you, and Viator receives only what any normal web link carries. We may earn a commission at no extra cost to you. A tour you tapped is saved in the trip (the tour's code, a short label and the link) so it shows up in "What to book".
• Tiqets to find out whether an attraction in your itinerary has a tickets page, our server searches tiqets.com for the place's name only, and the result is kept in a shared cache for up to a month. The "Tickets" button takes you to Tiqets with our affiliate code.
• The live flight search. The flight search screen in the app is Travelpayouts' own search engine, and its script loads from tpembd.com, only after consent as described under "Cookies and storage". While it is open it asks www.apistp.com where you are, so that it can fill in your nearest airport by itself: that company receives your IP address and returns your city, country and coordinates. What you type into the departure and arrival fields is sent to autocomplete.apistp.com as you type, and the currency table is loaded from api.apistp.com. The visit is also reported to Travelpayouts' analytics collector at avsplow.com, which receives the page address and its title, our affiliate code, the visitor and session identifiers described above, and your screen size, time zone and browser language. This happens only on the screen where that search appears.
• Other booking partners such as GetRentacar, Discover Cars, Saily, Booking.com, Expedia, Hotels.com, GetYourGuide, Suntransfers, Air Serbia, Vueling, LOT, trivago, Kiwitaxi and the Travelpayouts partners listed on the affiliate disclosure page, and companies the planner links to in the chat text, receive nothing until you tap through to them, and then only what a normal web link carries.
• Google Places, Google Routes and Wikipedia Google Places receives the name of a place, and its coordinates where we know them, when we look up its photo, rating, reviews or opening hours. When we show car rental desks on the map, it receives only the airport code (and its city name) or a rounded point in the city centre, nothing about you, and the result is kept in a shared cache for up to 30 days. Google Routes receives the coordinates of two stops in your itinerary, the travel mode and the hour, to work out travel time, and the result is kept in a shared cache for up to 30 days. Wikipedia receives the name of a place. Place photos are loaded by your browser straight from Google's servers, which receive your IP address.
• OpenStreetMap (Nominatim) when you search for stays "in this area" on the map, our server sends OpenStreetMap's Nominatim service the coordinates of the centre of the map (not your location) to get the name of the street or neighbourhood. The result is kept in our server's memory for up to a day.
• DuckDuckGo receives a search phrase built from a place and city name when we look for trending videos, and TikTok, Instagram and YouTube are where those videos and their cover images come from. Opening one takes you to that company's own service, under its own policy.
• MET Norway, NASA POWER and Google the Norwegian Meteorological Institute (MET Norway, api.met.no) receives your destination's coordinates and returns the forecast for the coming days. For days that have no forecast yet, NASA POWER (power.larc.nasa.gov) receives the same coordinates and returns 20-year weather averages. Our server gets those coordinates, and the destination's country for public holidays, from Google Places, which receives only the city name for this. When we look for a hotel's page on Booking.com, Google Places also receives the name of a town from the search result, with the hotel's location rounded to about ten kilometres, so that we can check on our side that the town is near the hotel. None of them receives your dates or anything that identifies you, and the requests go from our server, not from your browser. We keep the results in a shared cache: a city's coordinates for up to 90 days, the forecast for up to two days and the averages for up to 120 days. Weather data from MET Norway is licensed under CC BY 4.0. date.nager.at receives the country for public holidays, and api.frankfurter.dev is used for currency rates.
• Maps. The site loads Google Maps in your browser, so Google receives your IP address and your interactions with the map. In the app, the Android map screen loads the Leaflet map library from the unpkg CDN and map tiles from OpenStreetMap, so both receive your device's IP address while a map is open. On iPhone the app uses Apple Maps through the system.
• Voice typing, on the site. When you tap the microphone button next to the message box, your browser asks for microphone access and records until you tap it again, for up to two minutes. When you stop, the recording is sent to our server, which passes it to Groq (and, as a backup, Google Gemini) to get back the text and the language you spoke in. We do not keep the recording: it is discarded as soon as the text comes back. In browsers that have their own speech recognition, the words also appear in the box while you speak: for that, Chrome sends the audio to Google, Safari to Apple and Edge to Microsoft, under each company's own policy. Your browser remembers the last language detected (mh.voice.lang) so it listens in that language next time. The text is not sent by itself: it reaches Mighty only when you tap send, like any message you type. You can turn microphone access off at any time in your browser settings.
• Your phone's location, in the app only. The app asks for location access only when you tap the location button on a map, and only while you use it, never in the background. Once you allow it, the map shows where you are, and during a trip the app sends the coordinates to our server to find places near you: the server sends them to Google Places, and the results are kept in a shared cache by a cell of about 300 metres for an hour, with nothing that identifies you. When you ask a question about your trip, the coordinates go with the question to the AI provider that writes the answer. We do not store the location itself. The site does not ask for your device's location. You can turn the permission off at any time in your phone's settings.
• Vercel hosts the service and processes every request. Like any server, it records the IP address, the address requested, the time and error messages in request logs, and keeps them for a limited period under its own settings. The site, but not the app, also uses Vercel Web Analytics (counting visits and pages) and Vercel Speed Insights (page-speed measurements from your browser, such as how long a page takes to load, together with the page address, device and browser type, and country), which the provider describes as cookieless.
• Fonts and images, on the site only. Your browser loads fonts from Adobe Fonts (Heebo we serve from our own server), flags from flagcdn.com and airline logos from Aviasales (pics.avs.io) and Google. Each of those receives your IP address when the file loads. The app loads none of them.

Providers' own policies

Each provider has its own privacy policy. The main ones:

• Google (Firebase, Gemini API, Maps, Places, Routes, Fonts): https://policies.google.com/privacy , and the Gemini API terms: https://ai.google.dev/gemini-api/terms
• Anthropic: https://www.anthropic.com/legal/privacy
• Groq: https://groq.com/privacy-policy
• Vercel: https://vercel.com/legal/privacy-policy
• Expo: https://expo.dev/privacy
• Adobe Fonts: https://www.adobe.com/privacy.html
• Booking.com: https://www.booking.com/content/privacy.html
• Meta: https://www.facebook.com/privacy/policy/
• OpenStreetMap: https://osmfoundation.org/wiki/Privacy_Policy
• Wikipedia: https://foundation.wikimedia.org/wiki/Policy:Privacy_policy
• DuckDuckGo: https://duckduckgo.com/privacy
• The others publish their policies on their own sites: SerpApi (serpapi.com), Bright Data (brightdata.com), Travelpayouts (travelpayouts.com), Aviasales (aviasales.com), CJ (cj.com), Viator (viator.com), Tiqets (tiqets.com), AeroDataBox (aerodatabox.com), MET Norway (met.no), NASA POWER (power.larc.nasa.gov), GetRentacar, Discover Cars, Saily, Expedia (expedia.com), Hotels.com (hotels.com), GetYourGuide (getyourguide.com), Booking.com (booking.com), Suntransfers (suntransfers.com), Air Serbia (airserbia.com), Cloudflare (cloudflare.com), Twilio (twilio.com), WhatsApp (whatsapp.com) and UserWay (userway.org).

Shared trip links

If you use the share button, we create a public read-only page for that trip at a hard-to-guess address. Anyone who has the link can read that itinerary without an account, and can pass it on. The page also offers to add the itinerary to a calendar: a read-only calendar link derived from the same share link, containing only what the page shows (the stops with Mighty's times and notes, not the flight, hotels or tours you picked). Anyone who has the share link can subscribe to it, and a subscribed calendar keeps receiving changes to the itinerary until the share is cancelled.

The itinerary shown there contains only Mighty's replies, never your own messages, and the page title is built from Mighty's own words as well. Nothing you typed appears on a shared link, including in the link preview on social networks. If you asked Mighty to include a personal detail in the plan, it may appear there.

Do not share the link more widely than you intend. Deleting the trip cancels the link and its calendar link, and you can also ask us to revoke a share link.

Saved lists and sharing them

A saved list is stored in your account in Google Firebase, with its name and its places. When you add a place by name, from a video, from a photo or from a file, our server searches for the place's name in Google Places to find it on the map. When you import from Google Maps, the Takeout file you choose is read only in your browser and is not sent to us: we keep only the list names, the place names and their point on the map when there is one, and the place names are sent to Google Places to find them.

A "View only" link opens a read-only page with the list's name, its places and the map, with nothing about who made it. "Invite to add" needs a signed-in account on both sides: whoever opens the link sees the name and profile photo of the person who invited them, and whoever joins can add places. Everyone in the list sees the name and profile photo of everyone else in it, and who added each place. The list's owner can remove people and turn the invite link off, and anyone can leave the list. When someone leaves or is removed, their name and photo come off the list and the places they added stay in it. Deleting the list cancels its links and takes everyone out of it, and deleting your account takes you out of every list you joined.

The waitlist

On the waitlist page (mightyholiday.com/waitlist) you can leave an email address. It is stored in Google Firebase's Firestore database, together with the page language, which form on the page you used, when you signed up, and the random identifier of the anonymous account that sent it (so we can limit how many addresses are added from one browser).

Right after you sign up we send the address one email confirming it. Beyond that we use it only to email you about Mighty's official launch. We don't attach it to your account or trips, don't pass it to anyone except the email delivery service (Resend, see "Who else processes your data"), and don't send ads to it. We keep it until the launch email is sent, and no longer than 12 months. To have it removed sooner, write to hello@mightyholiday.com.

If you accepted analytics and third-party cookies, the Meta pixel tells Meta that a new signup happened, without your email address (see "Cookies and storage"). Signing up again with an address already on the list is not reported.

Calendar

If you tap "add to calendar", the app asks permission to write to your device's calendar and creates one event per timed stop. We read your calendar only to find one to write into. Its contents are never sent to us or to anyone else. Refusing the permission leaves everything else working.

On the website, "add to calendar" lets you subscribe to the trip in Google Calendar, Apple Calendar, Outlook or any other calendar app. The first time, we create a private calendar link for the trip at a random, hard-to-guess address. Your calendar fetches that link from time to time, so changes to the plan reach it by themselves. The link contains the stops with Mighty's times and notes, the flight, the hotels and the tours you picked, but not the messages you wrote. If you subscribe through Google, Microsoft or Apple iCloud, their servers fetch the link and see the plan, under their own terms.

The calendar link is private: anyone who has it can see the trip plan. Do not share it unless you mean to. The "add to calendar" menu has "Reset link", which creates a new link and cancels the old one at once; calendars subscribed with the old link stop updating. Deleting the trip cancels the link too. You can also download a calendar file without creating a link: the file is built in your browser and is not sent to us.

Why we use your data, and on what basis

We do not use your data to make automated decisions that have a legal or similarly significant effect on you. The AI writes trip suggestions, and you decide. No law requires you to give us any data: it is your choice, but without some of it (such as a destination and dates) the service cannot plan.

• To provide the service you asked for (performing our agreement with you): your account, keeping your trips, chat answers, flight, stay and tour searches, reading files and links you add, share and calendar links.
• For our legitimate interests, weighed against your privacy: security, preventing abuse and enforcing usage limits, caches that save cost, usage events and the AI request log to understand what works and fix problems, choosing a language by country, crediting commissions from affiliate links, and per-city totals of what people do with places (saving, adding to a trip, removing, skipping in the video feed and clicking to book), with nothing that identifies you and nothing you wrote in the chat, so the suggestions get better for everyone.
• With your consent: third-party widgets that set cookies (Travelpayouts' flight search), the Meta pixel, flight notifications, the calendar permission in the app, and "My preferences", all of which are optional. You can withdraw consent at any time, without affecting what was done before.
• Where the law requires it: for example to answer a binding request from a competent authority, or to protect legal rights.

Transfers outside Israel

We are based in Israel, and the providers described above process data on servers in the United States, the European Union and other countries. The European Commission recognises Israel as providing an adequate level of protection for personal data. Where the law requires safeguards for a transfer (for example from users in the EU or the UK), we rely on those the providers offer in their terms, such as standard contractual clauses (SCCs) or the EU–US Data Privacy Framework for providers that have joined it.

How long we keep things

Trips and saved places stay until you delete them or your account. Your "My preferences" answers stay until you change them or delete your account. Packing lists and usage counters stay with the account until it is deleted (deleting a trip does not delete its packing list). A profile photo you uploaded is kept until you replace or remove it, or until the account is deleted. The name, email address and Google photo of a signed-in account are kept by Firebase Authentication until the account is deleted. We do not currently delete inactive accounts automatically.

Usage event records (link clicks) are kept for up to 24 months and then deleted automatically, or sooner if the account is deleted. Lines in the chat's technical log (with no text of yours) are kept for as long as we need them for cost accounting, and are deleted with the account. Flight notification details are kept until you turn notifications off. A WhatsApp conversation is kept until you write "reset" (the messages), and is deleted entirely after 30 days without a new message, and so is a request for a person on WhatsApp (including the phone number). Vercel's request logs are kept for a short period under its own settings. Emails you send us are kept for as long as we need to handle and record your request.

Shared caches, which contain nothing that identifies you, are used for different periods: flight results up to three hours and stays up to six, flight status up to 24 hours, tours from one hour to a week, photos, ratings, opening hours, overviews, reviews and travel times up to 30 days, links read and trend videos about a week, weather up to 120 days, city locations up to 90 days, and converted affiliate links up to a year. After that an entry is no longer used, but it may stay stored until it is replaced by a new one.

Security

Traffic to and from the service is encrypted (HTTPS). Our database cannot be read or written directly from a browser: every access goes through our server, which checks your account. Share and calendar links use long random addresses. Only the operator can reach the admin tools. No system is completely secure. If a security incident affects your data, we will notify you and the authorities as the law requires.

Your rights

Everyone: you can ask to see the data we hold about you, get a copy of it, correct it or delete it. Under the Israeli Protection of Privacy Law you have the right to inspect your data and ask for it to be corrected, and you can complain to the Privacy Protection Authority.

Users in the EU and the UK: you also have the right to restrict processing, to object to processing based on legitimate interests, to receive your data in a portable format and to withdraw consent, and you can complain to the data protection authority in your country.

Users in California: you have the right to know what personal information we collect and why, to ask for it to be deleted or corrected, and not to be discriminated against for using these rights. You can use an authorised agent. We do not sell personal information. The Meta pixel, which loads only after consent, may count as "sharing" for targeted advertising under California law: to opt out, choose "Necessary only" under the "Cookie settings" link. In a browser that sends a Global Privacy Control (GPC) signal the Meta pixel does not load at all, even after "Accept all". If we turn down your request, you can appeal by email to hello@mightyholiday.com, and we will answer within 30 days.

How: you can delete your whole account yourself on your account page. For any other request, write to hello@mightyholiday.com. We may ask for something that shows the account is yours (for example the email address you signed in with, or, for an anonymous account, a share link to one of its trips). We will answer within 30 days.

Deleting your data

Deleting a trip in the app or on the site removes it from our servers and cancels its share and calendar links. Signing out does not delete anything.

Your account page has a "Delete my account" button, for anonymous and signed-in accounts alike. Once you type DELETE to confirm, our server immediately deletes everything tied to the account: trips and conversations, saved places, preferences and usage counters, packing lists, share and calendar links, flight notification details, usage events, the technical log lines of your trips, and any profile photo you uploaded, and finally the account itself in Firebase Authentication, including the name, email address and Google photo. Your browser clears its local copy, and a new, empty guest account is opened. This cannot be undone.

What is not deleted: data in the shared caches and the overall daily counters, which does not identify you; usage events of an earlier guest account that was merged into yours when you signed in, which stay under that earlier identifier; Vercel's request logs, kept for a short period under its own settings; emails you sent us; WhatsApp conversations and requests for a person in them, which are not linked to the account (write "reset" in them, as described under Twilio and WhatsApp); and the copies that the AI providers, Postmark and the other providers keep for a limited time under their own settings and terms (described under "Who else processes your data"), which we cannot delete. If the button does not work, or you want those removed as well, write to hello@mightyholiday.com and we will deal with it within 30 days. For a signed-in account, tell us the email address you signed in with. For an anonymous account, include a share link to one of its trips so we can find it.

Advertising, selling and sharing

There are no adverts in the app or on the site, and the app contains no advertising or tracking SDKs. We do not sell personal information or rent it out. The one exception for targeted advertising is the Meta pixel on the site, which loads only with your consent and is described under "Cookies and storage": through it Meta learns that you visited the site, got a plan, tapped a booking link or joined the waitlist, and uses that for our ads with it. Data goes to the providers described above only to run the service. Beyond that it may be passed on only in these cases: to a buyer or successor of the company or the service in a merger or sale, who will keep treating it under this policy; to our professional advisers (lawyers, accountants) under a duty of confidentiality; and to authorities when the law or a court order requires it, or when needed to protect rights, safety or against fraud. We may also use aggregated data that identifies no one (for example how many trips were planned for each city), and we will not try to re-identify people from it.

We earn money from affiliate links: when you tap one and book, the provider may pay us a commission. The link itself carries nothing that identifies you (only the name of the channel you came from, as described under "Cookies and storage"), but the provider or affiliate network sees the tap and may set a cookie on its own site to credit the booking to us. Details are on the affiliate disclosure page.

Children

The service is meant for adults and is not directed at children under 16, and we do not knowingly collect their data. If we learn that we have, we will delete it. If you tell us how many children are travelling with you and their ages, we use that only to plan the trip.

Changes

If this policy changes we will update the date at the top of this page. If we make a material change to how we use data we already hold, we will also say so on the site before it takes effect.

Who we are

The service is operated by Lavi Ben Gal, a company registered in Israel (company number 514945666). We are responsible for the data collected through the service (the database owner, or "controller" under the GDPR). For any question: hello@mightyholiday.com