Privacy Policy

This policy covers Stopover: what we collect when you plan a trip, why, who else sees it, and how to get rid of it. It is written to be read, so it says what the software actually does rather than what a policy template says.

1. What we collect

Your account

• Your email address, and a hash of your password, both held by Supabase Auth. We never see or store the password itself.
• Your name, as you typed it at sign-up, so emails and the account page can use it. If you sign in with Google instead, Google tells us your name and email address and nothing else we ask for.
• Sign-in metadata Supabase keeps: when the account was created, when you last signed in, and the one-time tokens behind magic links.
• Your free-trip allowance and how much of it you have used.

What you ask for

• Trip requests: your home airport, the cities, the date window, nights per city, number of passengers, the constraints you set, which hacks you turned on, and a two-letter nationality code used to tailor a few practical notes and to work out which rail pass you could buy. Not a passport number, not a date of birth, not a name.
• What you type into the plain-English trip box is read once, turned into a trip request, and not kept: we store the structured request it produced, not your sentence. The sentence itself goes to Anthropic on the way; see section 5.
• Your plan chat is not stored on our servers at all. It lives in your browser. Each message you send is processed to work out what to change, along with the plan you are looking at, and then it is gone from our side.

What we produce

• The plans themselves: itineraries, prices, layovers, links, explanations, stored against your account so they are there when you come back. A plan made without signing in is stored the same way, with no account attached, and is reachable only by its link. A plan also has a share link, and that link is the key: anyone you send it to can open the plan without signing in, so treat it the way you would treat any link you would rather not post in public.
• A usage ledger: one row per request, holding who asked, what kind of request it was, how many live searches it spent, which plan it belonged to, when, and a little about the request itself: for a plan, how long it took, how many cities it covered and which earlier plan it re-planned; for a live price check, the route and the date you checked. “Who asked” is your account id when you are signed in, and your IP address when you are not, which is the case for a plan made without signing in and for everything on a deployment that has no accounts. This ledger is what enforces the free-trip allowance and the abuse limits. Address-keyed rows expire quickly; account rows do not (see section 7).
• The site that sent you, stored on the plan: the hostname of the page you arrived from, or the word “direct” if you typed the address or came from a bookmark. A hostname and nothing else, so “google.com” and never the search you typed or the page you were on. When you came in on a link we handed out ourselves, one ending in something like ?ref=loop-email, it is that short tag instead, and the visit is counted once against it. It is read once when the tab opens, kept in that tab until you close it, and written on any plan you make and on your account if you create one there. It tells us which of the things we try is bringing anyone here.
• Counters: one row each time something worth counting happens, holding the name of the event, the moment, and a few facts about it with no free text in them: which booking site a link went to, how many cities a plan had, roughly how long it took, whether it failed and why. Since 20 September 2026 an event that happens on a plan also carries that plan’s id, which is what lets us see a session as a sequence rather than a pile: this plan was asked for, finished, and then a booking link was opened. The rows carry no account id and no address, and the plan id only points at anything for as long as the plan exists.
• Fare observations: for a route, date and passenger count, the cheapest fare we saw, the cheapest nonstop, and a compact copy of the few best results. This is about flights, not about you, and it is not linked to your account or your address. It is what makes the price cache and “cheaper than last week” work.

Technical

• Your IP address. It is in ordinary server logs, and it is also the identifier the usage ledger uses for anyone who is not signed in, which means a stored row can say that an address ran a search, or checked a particular route on a particular date. Those rows are what stops one machine from spending everyone’s search budget. They are not connected to any account, and they are deleted on a short schedule.
• Error reports when something breaks, including the page you were on and a stack trace. When the page itself breaks, the report also carries a short replay of what the page did in the moments before: its layout and where you clicked, with every piece of text on the page and everything you typed hidden, so the replay shows the shape of what went wrong and not your trip or your details. Ordinary visits are never recorded. Some page loads and requests also send how long they took, so we can find what is slow. All of it goes to Sentry where it is enabled.
• Page views, load timings, and the same counters described above, through Vercel Analytics and Vercel Speed Insights, which run on every page of this site. Page views and timings are what those products are for: which page was opened, the referrer, how long it took to become usable. The counters go there too, under the same names and with the same rounding, so book_click and how long a plan took reach Vercel as well as us. Nothing is attached to them that is not attached to the counters: no plan id unless the counter carries one, no free text, numbers rounded to buckets. Vercel documents both products as collecting no cookies and no identifiers that follow you between sites. This entry was missing until 23 September 2026, which was an omission and not a change: all of it has been running since the site launched, and the first version of this sentence, written the same day, described only the page views.
• A small badge at the foot of every page, loaded from tools.cafe, a directory that lists this site. Your browser asks their server for the image, as it would any image host, so they see your address, your browser and that a page of this site asked for it. Nothing else is sent to them. Added 24 September 2026.

2. What we do not collect

• No card or bank details. A pass is paid for on Stripe’s own checkout page, so the card number goes to Stripe and never to us. What we keep is the receipt: which account paid, the amount, the currency, when, Stripe’s id for the payment, and whether it was refunded. Stripe handles the payment under its own privacy policy.
• No passport numbers, dates of birth or travel-document details.
• No location tracking, no device fingerprinting, no advertising cookies, no ad networks and no data brokers. The fonts are served from this site, not from Google.
• No purchase of data about you from anyone else.

3. Why we hold it

• To run the thing you asked for: search fares, build the plan, show it to you again later.
• To enforce the free-trip allowance and the rate limits, which is what keeps live searches affordable for everyone.
• To find and fix faults, and to see which parts of the planner are failing.
• To email you about your account: sign-in links, password resets, and notice of changes that matter.
• To email you when the fares for a trip you planned while signed in have dropped by at least $25 a person and 5% of what they were, at most once a week for each trip, and only for two weeks after you plan it. Every one of those emails has a link that stops them, and deleting your account stops them too.

Where the GDPR applies, our bases are performance of a contract (running the service you signed up for) and legitimate interests (security, abuse prevention, and keeping the service working).

4. Cookies and what your browser keeps

There is no cookie banner because there is nothing to consent to. Neither cookie below tracks you, and neither is shared with anyone.

• Session cookie (set by Supabase): holds your access and refresh tokens so you stay signed in. Strictly necessary; clearing it signs you out.
• Passcode cookie, only on a deployment kept behind a shared passcode: it holds the passcode you typed so the gate does not ask again. The public site does not use one.
• Local storage, which stays in your browser and never reaches us: the list of plans you have opened on this device, your plan chat history, a small cache of fares you checked live so the same leg does not re-check, a flag saying you have seen the results introduction, and, on deployments that use one, the access passcode.
• Session storage, which your browser throws away when you close the tab: the hostname of the site you arrived from. Unlike the entry above it, this one does reach us, because it is written on any plan you make while the tab is open (section 1). It is held in the tab because the browser only says where you came from once, on the first page you land on, and by the time you press Plan it has forgotten.

Clearing your browser storage removes all of that. Your account and your saved plans are unaffected.

5. Who else touches it

We use a small number of services to run this. None of them is paid to profile you.

• Supabase: accounts and the database (Postgres, US East). Holds your email, your plans, and the usage ledger.
• Vercel: hosts the website, so it sees every request to it, including your IP address, in its logs. Through Vercel Analytics and Speed Insights on every page it also receives page views, the referrer, load timings and the same counters we keep (section 1), with no cookies.
• Resend: sends our email, the sign-in links and, if the fares for a trip you planned drop, the email saying so. It is given your address and the email itself. It also carries two emails to us, never to anyone else: a daily report on the service, which lists new sign-ups’ email addresses and each day’s plans (the route, party size, price and the site that sent the visitor, not who made them), and your request for more trips if you send one, with the name and message you wrote.
• Cloudflare Turnstile: the check on the sign-in and sign-up forms that a person is filling them in. Cloudflare sees that page visit and your browser’s signals for that check, and nothing about your trips.
• Google: if you choose “Continue with Google”, it signs you in and tells us your name and email address.
• Google Cloud Run: where the planner itself runs, so a long search is not cut off by a serverless timeout.
• Sentry: error reports, the replay of a page that broke (its text and your typing hidden), and how long pages and requests took, where it is enabled. May include your IP and the URL you were on.
• Anthropic: the language model, on every plan, not only when you type a sentence. Your identity is never part of what is sent, and where no model key is configured the planner writes the explanation itself and none of this leaves at all. Three separate things go to it:
  • The explanation, on every plan. When the plan is finished we send a draft paragraph and a short JSON summary of the winning itinerary, and the model rewrites it. That is: the city codes in the chosen order, including your home airport; the travel dates; the price per person and the group total; the number of travelers; and up to three long-layover cities and two add-on suggestions. It is not sent your email, your account id, your IP address, your nationality code, or anything you typed.
  • The plain-English trip box. Your sentence, as typed, so it can be turned into a trip request.
  • The plan chat. Your message, the last few turns of the conversation, and the plan you are looking at (its order, dates, nights, legs, airlines and fares) so the answer is about your trip and not a generic one.
• Fare sources. Each is sent one leg at a time, meaning an origin, a destination, a date and a passenger count, and nothing else. Not your email, not your account id, not the rest of your route.
  • Firecrawl: fetches the Google Flights results page for us from its own proxies, so the request Google sees is Firecrawl’s and not yours.
  • Google: the same results page, fetched directly by our server when the proxy is not in use.
  • SerpApi: a second route to Google Flights results, where a key is configured.
  • Kiwi.com and Ryanair: free, keyless fare and date-grid searches.
  • Travelpayouts: cached fares and route estimates.
  • Duffel: airline offers, used to verify a price on deployments where its token is set.

When you click through to book, you leave us. Google, Skyscanner, Kiwi.com, Aviasales, Rome2Rio (for a train, bus or ferry leg) and the airlines have their own policies and their own trackers, and this one stops at our edge.

6. We do not sell your data

We do not sell personal information, and we do not share it for cross-context behavioural advertising, as those terms are used in California law. We have never done so and there is no plan to. Some booking links can carry an affiliate marker that identifies this site as the referrer; it is the same code for every visitor, it says nothing about who you are, and it does not change the price you are quoted or which itinerary we recommend.

7. How long we keep it

• Account and plans: until you delete the account, or until the service shuts down. Nothing ages them out on its own.
• Usage ledger, account rows: kept for the life of the account, because the free-trip allowance is counted over the whole life of the account. Deleting your account deletes them.
• Usage ledger, address-keyed rows: deleted within three days of the request. A row is due to go after 48 hours, because the longest limit any of them feeds is a rolling 24 hours, so nothing older has a job to do. A nightly sweep does the deleting, so a row can outlast its 48 hours by up to a day.
• Cached fares: a fare we searched live goes stale after 12 hours; a fare that came from a source of already-cached fares after 24 hours. Expired rows are dropped by the same nightly job.
• Fare observations: kept indefinitely. They contain no personal data: a route, a date, a party size and a price, with nothing tying them to you. For the two weeks after a plan finishes, a nightly job re-prices its legs and adds an observation for each, which is what lets a saved plan tell you what its fares have done since without searching anything again. Nothing about the plan or the account is written alongside them, and they outlive the plan they came from.
• Counters: kept indefinitely, because their whole use is comparing this month with last. Deleting your account does not delete them. It takes the plan id off the ones that carry it, so what is left is a count of something that happened with no way back to you. The rest of a counter row was never about you.
• Error reports and replays: kept by Sentry for up to 90 days. Timings: up to 30 days.

8. Deleting your account

There is a delete button on your account page. It asks you to type the word delete to confirm, and then it deletes, immediately and without anyone reading it first:

• your Supabase auth record and your profile row, including your allowance;
• every plan tied to your account, which also breaks its share links;
• every usage-ledger row keyed to your account;
• any request you sent asking for more free trips, including the message you wrote with it.

What survives, because it is not about you:

• fare observations and cached prices, which record what a flight cost on a date and never carried your identity;
• address-keyed ledger rows, if you ever used the site without an account. Nothing links them to the account you just deleted, and one address can be a whole household, so deleting by address would hand a stranger a fresh rate limit. They expire on their own within three days instead;
• counters, with the plan id stripped out of every one that had it. What survives is that a plan was made and a booking link was opened, not by whom;
• your plan chat and your saved plans in this browser, which were never ours to delete. Clear this site’s data and they are gone;
• ordinary server and error logs, which age out on their own schedule;
• your email address, on a list of addresses that have been deleted, and this one is worth reading twice. It is kept so that the same address cannot be used to make a new account, which stops a deleted account being re-made to collect the free trips again. Nothing else is kept with it: not your name, not your plans, not what you searched for. The practical effect is that deleting your account also closes this site to that address for good. If you would rather that not be true, email pathakansh10@gmail.com before you delete and we will remove the address by hand afterwards. This entry was missing until 23 September 2026.

If the button ever fails, or you cannot sign in to reach it, email pathakansh10@gmail.com from the address on the account and we will do the same deletion by hand within 30 days.

9. Your rights

Depending on where you live, you can ask for a copy of what we hold about you, ask us to correct it, ask us to delete it, ask for it in a portable form, or object to a use of it. Email pathakansh10@gmail.com and we will answer within 30 days. We will not treat you differently for asking. If you are in the UK, the EU or a US state with its own privacy law, you can also complain to your data protection authority.

One honest limit: an address-keyed ledger row carries no account and no name, so we cannot tell whether it is yours and we will not go looking. Rather than answer such a request badly, we delete every one of those rows within three days.

10. Security

• Everything runs over TLS, and the database connection is encrypted.
• Every application table has row-level security enabled with no policies, so nothing is readable through Supabase’s public API.
• Service keys and API keys are server-side only and never reach your browser.
• Passwords are hashed by Supabase. We could not tell you yours if we wanted to.
• A plan is fetched by its id and not by who you are, which is what lets you send a plan to the people you are travelling with. The id is random and short, and a plan holds a trip, not an identity. But it is a link, so guard it like one.

No system is perfect. If you find a hole, email pathakansh10@gmail.com before you publish it and we will fix it.

11. Where the data lives

Our database and the planner run in the United States. If you use the site from outside the US, your data is transferred there. Where the GDPR applies, those transfers rely on the standard contractual clauses our providers offer.

12. Children

This is not for children. Do not use it or create an account if you are under 13. If we learn we hold data from a child under 13, we delete it.

13. Changes

We will update this page and its date. If a change means we start doing something genuinely new with your data, we will email account holders before it takes effect.

14. Contact

The controller of your data is Stopover, based in Texas. Reach us at pathakansh10@gmail.com. The Terms of Service cover everything else.