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.
- 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 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 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).
- 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. Sent to Sentry where it is enabled.
2. What we do not collect
- No card or bank details. We take no payments today; when we do, a payment processor will handle them and we still will not store card numbers.
- No passport numbers, dates of birth or travel-document details.
- No location tracking, no device fingerprinting, no advertising cookies, no third-party analytics. 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.
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.
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 — hosting for the website.
- Google Cloud Run — where the planner itself runs, so a long search is not cut off by a serverless timeout.
- Sentry — error reports, 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 travellers; 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 — 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 48 hours after the request. 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, which means the true outside limit is three days.
- 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.
- Error reports: kept for the retention window of the error tool, typically 90 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.
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 inside 48 hours instead;
- 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.
If the button ever fails, or you cannot sign in to reach it, email [[CONTACT_EMAIL]] from the address on the account and we will do the same deletion by hand within 30 days.
Do it yourself, right nowPlans and chat history saved in this browser are yours alone: clearing this site’s data in your browser settings removes them immediately, without asking us.
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 [[CONTACT_EMAIL]] 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 after 48 hours.
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 [[CONTACT_EMAIL]] 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, and note anything material in the changelog. If a change means we start doing something genuinely new with your data, we will email account holders before it takes effect.
The controller of your data is Stopover, based in [[JURISDICTION]]. Reach us at [[CONTACT_EMAIL]]. The Terms of Service cover everything else.