Privacy policy

This policy explains what OurTrip.Page does with personal information when you join the waitlist, hold an account, or read a trip page on ourtrip.page. It is written to be read, not to be survived. If something here is unclear, ask us at hello@ourtrip.page and we will answer in the same register.

One thing is worth saying before anything else, because everything below follows from it: a trip page is meant to hold the confirmation number, the door code and the address. That is why it is worth opening on the morning of a flight. We store that page exactly as you wrote it, we do not scan it, redact it or strip anything out of it, and we serve it only to the email addresses you name. What goes onto the page is your decision, and the consequences of that decision are described in section 9.

1. The two kinds of data here

They are governed differently and it matters which one you are asking about.

Account data — the small amount we need to know who you are and let you in: your email address, your subdomain, your plan. We decide what to collect and why, so for this data we are the controller.
Trip content — the pages, the files you or your agent archive alongside them, and your traveler profile. We hold and serve these on your instructions and do not use them for anything of our own. For this data you are the controller and we act as your processor. If your trip mentions other people, you are the one who decided to include them.

2. What we collect

If you join the waitlist

Your email address.
The optional free-text note ("where are you going?"). It is stored as typed — please do not put anything sensitive in it.
The referring page your browser reported, and the time you submitted, so we know roughly where people are finding us.
Your IP address, briefly, as a rate-limit key so one machine cannot flood the form. It is stored against a counter that expires, not against your entry.

Joining does nothing else. No account is created, no email is sent, and nobody is contacted until a human decides to invite you.

If you hold an account

Your email address. An address on the allowlist is the key to what it can read.
Addresses you invite to a trip. When you share a page, we store the address you typed, which trip it may open, and when you added it — and we email that person once to tell them. Because a sign-in code is only ever sent to an address we already hold, an invitation also creates an empty account for them to sign in as: an identity and nothing else, with no subdomain, no repository and no trips of its own. Removing them deletes the invitation, and takes effect on the next page they ask for. If they never sign in, that account holds their address and nothing more; they can ask us to delete it, like anybody else.
The account record: an opaque account id, your chosen subdomain, plan, status, when it was created, and a pointer to the git repository that holds your trips.
Sign-in material: a salted hash of the current six-digit code — never the code itself — its expiry, and the number of failed attempts. It is deleted the moment the code is used or expires.
Session records for signed-in browsers and OAuth tokens for AI clients you have connected.
Operational counters keyed by email address or IP address for rate limiting, which expire on their own.

Your trip content

The page itself — one HTML file per trip, stored byte for byte in a private git repository and copied unmodified into object storage for serving. Whatever is on it, we have: flight numbers, booking references, addresses, door and wifi codes, the names of the people travelling with you.
Archived sources — the confirmation emails, PDFs and screenshots you or your agent file alongside the page. These are stored in your repository and are never served to any reader, including you, through the website.
Your traveler profile, if you create one: the preferences you choose to record. It is a file you can read, edit and delete like any other.
A derived text index. When a page is published we also extract its visible text into our database so that searching your own trips is fast. It is a copy of words already on your page, it is only ever queried for you, and deleting the trip removes it.
Git history. Every edit is a commit. Earlier versions of a page remain in the repository's history until the repository is deleted — so removing something from a page removes it from what we serve, but not from history. See section 7.

Automatically, while serving requests

Standard request metadata — IP address, user agent, hostname, timestamp — passes through our infrastructure provider and appears in short-lived operational logs used for security and debugging. We run no analytics, no advertising pixels, and no third-party trackers on the marketing site or on trip pages.

3. What we do with it

Let you in — issue and check sign-in codes, mint sessions, authorize AI clients.
Decide, on every single request, whether the person asking is on the allowlist for that trip. This is the whole product.
Store, version and serve your pages, and keep your search index current.
Send the few emails the service requires: your sign-in code, your invitation, a notice when a trip you are on is published, and notices that materially affect your account.
Keep the service standing up — rate limiting, abuse prevention, debugging.
Comply with law.

What we do not do: we do not sell personal information; we do not share it for advertising; we do not profile you; we do not read your trips for product research; and we do not use your content to train AI models, our own or anyone else's.

4. Legal bases

Where the GDPR or a similar law applies, we rely on:

Contract — everything needed to give you an account and serve your pages, including telling you when a trip that has been shared with you is published. That is a service notice about content you are a party to, not marketing, so it is not something we ask consent for — but you can stop it whenever you like by leaving the trip.
Legitimate interests — security, abuse prevention, and keeping the service reliable, weighed against the fact that this is private data and the balance tips towards restraint.
Consent — the waitlist, which you can withdraw from at any time by asking us to delete your entry.
Legal obligation — where we have to keep or produce something.

5. Who else touches your data

Four parties, and we would rather name them plainly than describe a category. Three are ours; the fourth is yours.

Cloudflare — runs the service. Every request passes through it; your pages, your account records and your search index are stored on its object storage and database.
GitHub — stores your trips. One private repository per account, in an organization we control, named with an opaque id rather than your username so nothing about you leaks into a URL or a log line.
Resend — delivers our email. It handles your address and the contents of the message: your sign-in code, your invitation, and — when somebody publishes a trip you are on — that trip's name and the short note whoever published it wrote for the people on the list. Nothing else from the page travels by email. We derive no summary of what changed; the note is a sentence a person wrote and saw before it was sent. Codes are short-lived and single-use, because email is not a secure channel.
Your own AI assistant — not ours. If you connect Claude, ChatGPT or any other client to your trips, that client reads and writes the whole page, including everything sensitive on it, and the content travels to that provider under your agreement with them. We do not choose that provider, cannot see what it retains, and are not responsible for what it does with the content. OurTrip.Page itself sends no part of your trips to any AI model.

We may also disclose information if the law requires it, or to protect the rights and safety of users and the service. If we are ever compelled to hand over your data and are permitted to tell you, we will.

6. Where data is processed

The providers above operate globally, so your data may be processed outside the country you live in, including in the United States. Where transfer safeguards are required we rely on the mechanisms our providers offer, including Standard Contractual Clauses.

7. Keeping it, and deleting it

Trips are kept for as long as your account exists. You or your agent can delete a trip at any time; the served copy and its search index go immediately.
Git history keeps prior versions of a page until the repository itself is deleted. This is the same mechanism that gives you undo and an audit trail, and it cuts both ways: if you commit something you did not mean to publish, deleting it from the page does not erase it from history. Ask us and we will delete the whole repository.
Account deletion removes the account row and everything that hangs off it — allowlisted addresses, sessions, tokens, hosts, search index — and deletes your repository and the served copies of your pages. Email us and we will do it; we aim to complete it within 30 days.
Sign-in codes live ten minutes at most. Sessions last seven days, extending while you keep reading. Rate-limit counters expire within hours.
Unpublished changes — the working copy a page has before it is published — are kept until they are published or discarded, and are readable only by you and by anyone you made an editor. Publishing turns them into a version; the note that goes out with it is not kept as a record of its own, only as the name of that version and in the message our email provider delivered.
Waitlist entries are kept until we invite or decline you, and deleted on request at any time.
Operational logs are short-lived and retained by our infrastructure provider under its own schedule.

8. How it is protected

These are the actual mechanisms, not aspirations:

Nothing is public. Not once. There is one copy of each page and no public variant of it. Every response is checked against the allowlist, marked no-store, and never indexed.
No password to steal. Sign-in is a single-use six-digit code, valid ten minutes, capped at five guesses, stored only as a salted hash.
The allowlist never answers questions. Asking for a code looks identical whether or not the address is known, so the service cannot be used as a directory of who has an account.
Session cookies are host-only. No cookie ever spans .ourtrip.page, so one tenant's page — which may run its own JavaScript by design — can never reach another tenant's session.
Encryption in transit everywhere; .page is an HSTS-preloaded domain, so plain HTTP is not an option even by mistake.
Repositories are private, opaquely named, and one per account.
Archived source files are never exposed through the website at all.

What this does not include: your pages are not end-to-end encrypted, and we hold them in a form we could read. That is a deliberate trade — a page we cannot read is a page we cannot serve to your travel companion at breakfast — and it means our staff and our providers' staff have the technical ability to access content. We access it only to fix a fault or when required by law.

No system is perfectly secure, and we will not claim otherwise. If a breach affects your personal data we will notify you and any regulator we are required to notify, without undue delay.

9. Sensitive information, and the risk you are accepting

Read this section even if you skip the rest. You choose what goes on a trip page and you accept the risk of it being there.

What you are consenting to when you use OurTrip

By putting information on a trip page — yours or anybody else's — you confirm that you are doing so voluntarily, of your own choosing, and at your own risk, and that you understand:

We store it verbatim. There is no filter, no redaction and no classifier between what you write and what we keep. A password typed into a page is stored as a password typed into a page.
An email address is the key. Anyone who can read the mailbox of an allowlisted address can receive a sign-in code and open the page. Your trip is exactly as private as the least-protected inbox on its allowlist.
You control the allowlist, including your mistakes on it. A mistyped address you happen to send to a real mailbox is access granted to a stranger.
Access can be revoked; disclosure cannot. Removing someone stops the next request. It does not un-read, un-screenshot or un-forward what they already saw.
Publishing sends email. When you publish a trip, everyone on its allowlist gets a message with the trip's name and the note you wrote. That note leaves the page, travels unencrypted, and lands in each of their mail providers — so it belongs at the level of "the hotel moved to the 14th", never a door code or a reference number.
Your AI assistant sees everything on the page. Connecting an agent sends the whole document, sensitive parts included, to a company that is not us.
Other people's details are your responsibility. If you record a companion's passport number, a child's date of birth or a friend's address, you are asserting that you are entitled to do that.

Please do not put these on a page

Nothing stops you technically, and we ask you not to anyway, because a trip page is not built to be a vault:

Full payment card numbers, CVV codes, or bank account credentials.
Passwords, API keys, or recovery codes for any account.
Passport scans, national ID numbers, visa documents, or images of them.
Health, biometric, religious, political or other special-category data about anyone, beyond the minimum a trip genuinely needs.
Anything about another person that you have no right to record.

A booking reference, a door code and a flight number are exactly what this product is for. A photograph of a passport is not.

10. Cookies

We use one kind of cookie: a host-only session cookie set after you sign in, so a page knows it is you. It is strictly necessary, it carries no tracking identifier, and it is not shared with anyone. There are no analytics or advertising cookies on this site, so there is no consent banner to dismiss and no preferences to manage.

Your own trip pages are files you control and may contain whatever markup you or your agent put in them. If you add something that sets a cookie, that is yours, not ours.

11. Your rights

Depending on where you live you may have the right to access, correct, export, delete or restrict the processing of your personal data, to object to processing, and to complain to your data protection authority. Some of these you can exercise without asking us: your trips are files in a git repository you can clone, which is export; editing a page is correction; deleting a trip is deletion.

For everything else, write to hello@ourtrip.page from the address on the account. We will respond within the time the applicable law allows, and normally much sooner.

If you are in the United States: we do not sell personal information, we do not share it for cross-context behavioural advertising, and we do not use it for targeted advertising.

If someone else's details appear on a trip page and you want them removed, contact us and we will pass the request to the account holder, who is the controller of that content, and act where the law requires us to act directly.

12. Children

Accounts are for adults: you must be 18 or older to hold one. We do not knowingly create accounts for children. Trips are often family trips, and a page may well name a child and their seat on a flight — that is ordinary and expected. Record only what the trip actually needs, and remember that you are responsible for it.

13. Changes

We will update this policy when what we do changes. The effective date at the top always reflects the current version, and we will tell account holders by email about any change that materially affects them. Continuing to use OurTrip.Page after a change means the updated policy applies.

14. Contact

Privacy questions, data requests, deletion, or anything on this page: hello@ourtrip.page.