Privacy Policy

Account information. When you sign in, our authentication provider (Auth0) gives us your email address and display name, which we use to identify your account, address invitations to you, and associate in-app notifications with the right account.

Content you create. The trip data you enter and upload: trips, dates, itinerary items (lodging, transportation, restaurants, activities) and notes; places and addresses you add; trip budgets and expenses, including descriptions, amounts, currencies, payers, splits, settlements, and receipt links; cash or reward-point costs; reward-program names, nicknames, notes, and optional last-four references; documents and photos you attach (such as receipts); emails you forward to your TripToad import address or paste in so we can turn them into itinerary items; and collaborators you invite by email and their roles. TripToad does not provide a manual reward-program balance ledger or move money between travelers.

Read-only invitation and guest links. A pending email invitation is a time-limited bearer link. While it is pending and has not expired, anyone holding it can open a read-only preview without signing in; the preview also shows the inviter's name and the offered role. Separately, a trip owner can create a companion bearer link for an account-less participant. That link has no fixed expiry and works without sign-in until the owner turns it off or replaces it, or the participant links an account. Both link types expose the same shared companion projection, including itinerary and confirmation details, places, prices, points/program facts, participant names and Going/Maybe attendance, the linked participant's own nonzero per-currency balance, and non-Bucket planning blocks with each candidate's display title, preferred status, interested/Maybe tallies, and comment count. Bucket labels, candidate notes as a separate field, other participants' balances, comment bodies, and voter identities are not included. Treat either URL as a secret; its holder and ordinary network intermediaries also supply request metadata when it is used.

Camera and photos. With your permission, the app can use your camera and photo library so you can capture and attach receipts and images. We access these only when you choose to add a photo; we do not scan your library in the background.

Safety and policy records. When you report a trip member, comment, or AI-generated result, TripToad stores your account identifier, the reason and optional details you submit, a bounded snapshot of the reported content and its context, and the report’s review outcome. The ordinary trip view does not expose a reporter’s identity or moderation notes. You can also block a person: TripToad then keeps their comments out of your view and stops their comment notifications to you, without removing anyone from a trip or changing the plan. Your block list is stored with your account and is not shown to the person you blocked. When a versioned policy must be accepted before you can post, we record the exact version and time when you accept a versioned policy. No such acceptance is required today, so no acceptance record exists yet, and no Community Guidelines version is required unless TripToad has separately published and activated one.

Calendar access. If you choose to export a trip to a device calendar, the mobile app asks permission, lists writable calendars, and creates or updates the events you select. TripToad does not send that calendar list or those calendar events to its servers; your device’s calendar provider may sync them under your calendar settings.

When something goes wrong on the website or our servers, we send a report of the error to Sentry so we can fix it. The report says what kind of error it was, where in our code it happened, which version of TripToad was running and, for server errors, what kind of request failed. It does not include who you are, what you typed or anything from your trips, and we do not record your screen or track how you use the site.

Mobile diagnostics. Production mobile builds send crash reports and a limited sample of performance traces to Sentry. We do not attach your TripToad account identity. Session replay is captured only around an error, with all text, images, and vectors masked on your device before it is sent.

Mobile notification setup and optional notifications. The Android app includes Firebase components that can automatically create an app-install-specific Firebase installation ID and collect app version and routine device/app metadata when the app starts, before optional notifications are enabled. This is not a hardware or advertising identifier. Push availability still depends on the installed mobile release and external provider configuration. If push is available and you turn it on, we additionally store your account-level mobile-push preference, an app-generated installation identifier, the device platform, and an Expo push token. Provider messages use generic notification text and an opaque notification identifier rather than trip names, comments, or other trip content.

Web acquisition and product-use metadata. If the web landing URL includes utm_source, utm_medium, utm_campaign, or a ref referral value, TripToad keeps a compact first-touch copy in your browser’s local storage. After you sign in, we add that first-touch value to your account once; later tagged visits do not replace it. The service also records content-free product-use events, such as account, trip, itinerary, invitation, import, and assistant activity. An event can include its name, time, your account or trip identifier when known, and bounded identifiers, counts, or category values. It does not include email bodies, booking or document content, trip names, addresses, assistant messages, or other sensitive free-form content.

What we do not collect. TripToad does not request your device’s precise location, does not include third-party advertising, and does not sell your personal information.

Hosted calendar feed. If you create a calendar subscription, TripToad generates a revocable secret feed URL. A calendar provider or anyone holding that URL can fetch a minimized calendar containing the trip and item names and types, dates, times, time zones, place names and addresses, and links that still require TripToad sign-in. The URL itself authorizes feed access, so treat it as a secret and revoke it in TripToad when it should stop working. The polling calendar service also receives ordinary server request metadata.

Operational diagnostics. TripToad's servers record a server-generated request identifier, normalized method, registered route template, response status, and duration so we can secure and operate the service. A diagnostic event can contain opaque account, trip, import, expense, document, resource, or audit identifiers and provider or outcome information. Caller-supplied request identifiers and dynamic path values are not copied into these logs. These process logs are not used for advertising or cross-app tracking.

• To provide the core service (storing, organizing, mapping, and displaying your trips);
• To turn forwarded emails and uploaded receipts into itinerary items (this involves automated text extraction, see below);
• To look up places, addresses, time zones, and airports so your itinerary maps and displays correctly;
• To find, automatically select, and apply a Pexels cover image when an owned trip has no cover, using a search derived from that trip’s name, places, or addresses;
• To send trip invitations, maintain the in-app notification feed, and, where available and enabled, deliver eligible native push notifications;
• To understand which first-touch campaigns or referrals lead to an account and how core product workflows are used, so we can improve the service;
• To investigate content reports, take reviewed moderation actions, keep an operator audit trail, and prevent abuse;
• To record which exact policy version you accepted.

Some features use automated processing, including third-party AI, to save you typing. You can plan and edit an entire trip by hand. The informational Trip Brief described below is generated automatically after trip creation when an AI provider is configured. Imported bookings and other suggestions arrive as drafts you accept or discard, and a change the assistant wants to make is described to you first and happens only when you confirm it.

• Automatic Trip Brief. After you create a trip, TripToad can send derived destination labels, dates, and an optional purpose to Anthropic to generate an informational summary. TripToad stores that brief automatically, but the brief does not create or change itinerary items, ideas, tasks, bookings, expenses, or trip structure.
• Turning emails into itinerary items. When you paste a booking confirmation or forward one to your TripToad import address, we send that message’s text to Anthropic (the company behind the Claude AI models) to extract details (dates, times, places, and confirmation numbers) into a draft you review before anything is added.
• Trip-organization suggestions. If you ask TripToad to suggest how to group your trip (for example, “Suggest legs”), we send the relevant place names, addresses, coordinates, and dates to Anthropic to propose a grouping you can accept or discard.
• One-shot itinerary suggestions. This path uses Anthropic when it is configured. If Anthropic is not configured and the OpenAI fallback is configured, it can send the suggestion prompt and the limited itinerary context needed to OpenAI instead. A provider error does not silently switch providers or write placeholder content.
• The in-trip assistant. When you send the assistant a message, we send that message, the recent conversation in that chat, and context about the open trip (its name, dates, default currency, and your role on it) to Anthropic. If the assistant looks something up, what it found goes back to Anthropic so it can answer: that can include your itinerary, your cost and budget totals, and place-search results. If you attach a receipt to a request, what AWS Textract read off it goes to Anthropic as well: the merchant name, the date, the currency, the totals, and how many line items were found. The receipt image itself never does, and the assistant never receives the receipt’s own line-item text. If it wants to change your trip, it does not make the change. It returns a description of the change, and the change happens only when you confirm it. TripToad’s app servers do not store a chat transcript as conversation history, but the Web app keeps the transcript in that browser’s local storage and the Mobile app keeps it in AsyncStorage on that device, so the chat can persist after you close and reopen it. Clearing the browser’s site data or the mobile app’s storage removes that device-local copy; mobile sign-out also attempts to remove it. A proposed change is stored separately: we keep what the assistant proposed, what you decided, and what was saved, so the change can be shown back to you and undone. For each streamed reply, the server also keeps a content-free receipt containing cryptographic digests, length, provider, and delivery status rather than the transcript. If you report that reply, the exact reply displayed on your device is copied into the moderation report so an administrator can investigate it.
• Planning Gap options. When an editor asks for options on a Planning Gap, we send Anthropic the detected gap, the trip’s dates and currency, and the names, kinds and dates of the itinerary items and places around that gap. Item notes, email text, and internal identifiers never go. The reply is at most three short next steps that everyone on the trip can read; each one opens an existing TripToad flow for you to review and none of them books anything, changes your itinerary or money, or carries links, prices, schedules or availability claims. TripToad has no affiliate relationships.
• Reading receipts. When you choose to scan a receipt, we send that image or single-page PDF to AWS Textract to read its text. While you finish reviewing it, TripToad keeps the printed text of its lines, amounts and date on its own servers, with card and account numbers removed, so it does not need to be scanned again; that text is cleared when you save the expense or discard the receipt, and an unfinished receipt expires after 24 hours.
• Translating receipt lines. When an editor asks to translate lines on a receipt, we send Anthropic only the text of the lines they choose, as printed or as corrected, and the language they want. That text can include quantities or prices printed on those lines; email addresses and long card or account numbers in it are replaced first. The receipt image, the amounts recorded, the merchant, the payer and the people on the trip never go. A translation never changes an amount or confirms any money. Saved translations are shown to people on the trip who can see that receipt.

TripToad sends this data to Anthropic, OpenAI when the fallback path is selected, and AWS only to provide these features. They process it under their own terms and our configured API relationship; provider retention and model-training terms can change. We do not send your data to these providers for advertising, and we do not sell it.

Forwarding a confirmation to your TripToad import address grants us nothing beyond that one message. Connecting a mailbox is different, and this section applies only if you choose to connect one. Connected mailboxes may not be offered in every release; when they are, connecting is always your explicit action on a Google or Microsoft consent screen, and you can end it at any time.

What we ask for. Read-only access to mail. For Gmail that is the single https://www.googleapis.com/auth/gmail.readonly permission and nothing else: the mailbox’s own profile tells us which address you connected, so no separate identity permission is requested. For Outlook.com it is the Mail.Read permission together with the sign-in permissions (openid, email) that tell us which address you connected, and offline_access so syncing can continue between visits. TripToad never asks to send, modify, delete or label mail, and never asks for your contacts or calendar.

What we read. Roughly every fifteen minutes TripToad lists recent messages and looks only at what a mail list shows: sender, subject and date. A message is opened only when its sender or subject matches a named travel signal (an airline, hotel, booking site or rail operator, or a subject such as “booking confirmation” or “e-ticket”). The rest of your mail is never opened, and Gmail’s body preview is excluded from the listing on purpose. After each sync the app tells you how many subject lines were checked and how many messages were opened.

What we keep. The access and refresh tokens the provider issues, encrypted at rest; the position of the last sync; a record of which message ids we already looked at, kept for up to 90 days so a message is not imported twice; and, for a message that was opened, its text as an import you review in TripToad. Message text is processed as described under Automated processing and AI, and only with your AI processing consent. Nothing is added to a trip until you accept it.

Ending access. Disconnect deletes the stored tokens and the sync position. The message-id record is shared by your mailboxes of the same provider, so it is deleted when the last of them is disconnected, and it expires on its own within 90 days in any case. For Gmail, TripToad also asks Google to revoke its access at that moment; you can confirm or revoke it yourself at any time from your Google Account permissions page. For Outlook.com the disconnect is local, and you revoke TripToad from your Microsoft account security page. Imports you already accepted are kept as trip content. Deleting your account revokes a connected Gmail grant and removes the stored tokens as part of deletion; a connected Outlook.com mailbox has to be disconnected first, because Microsoft offers no way for TripToad to revoke that grant on your behalf.

TripToad’s use and transfer of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. Data obtained through a connected Gmail account is used only to provide the connected-inbox feature to you; it is not used for advertising, is not sold, and is not read by a person except with your permission, for security purposes, or as required by law.

Collections start private. If you explicitly publish one, anyone can see its collection name, destination, category, chosen titles, place identities and source links, discover it and save selected recommendations. Publishing does not share your private trip dates, bookings, People, payments or notes. You can withdraw a publication; public access then stops, but copies someone already saved into their trip remain theirs.

Before your first publication, we record your agreement to a version of the Community Guidelines. Signed-in users can report public collections. Moderators and Admins can remove public content and suspend or restore public posting for spam or abuse; these actions are recorded. Posting suspension does not prevent private trip use, reading, reporting, export or account deletion.

Your account export includes owned private collections, publication data, current posting-permission status and policy acceptance history. Reports and internal moderation evidence follow the existing safety retention rules and are not exposed as someone else’s account export. Deleting your account removes your collections and publications; filed safety evidence may be retained under the safety rules described below.

We use a small set of trusted providers to run the service. They process data on our behalf under their own terms; we do not sell your data to anyone.

For the providers named here, those terms are data-processing terms: our sign-in provider (Auth0), our email providers (Mailgun and Resend), our notification delivery providers (Expo and Firebase Cloud Messaging), our error monitoring (Sentry, under a data processing amendment with data kept in the United States), our content delivery and public image storage (Cloudflare), the AI providers described in the AI section (Anthropic and, for one itinerary suggestion path, OpenAI), and Amazon Web Services, which reads a receipt only when you ask us to scan one. Each of those providers is bound by those terms to handle that data only on our instructions. Our AWS account is configured so that receipts are not used to improve Amazon’s services, and Anthropic retains prompts for its standard thirty days. TripToad’s servers are in the United States. We do not share your information for advertising.

We may also disclose information if required by law, or to protect the rights, safety, and security of TripToad and its users.

Data is encrypted in transit (HTTPS/TLS). We store your data on secured servers and take reasonable measures to protect it. No method of transmission or storage is completely secure, so we cannot guarantee absolute security.

Cloudflare R2 is where TripToad is set up to store service backups. When that deployment-managed backup job is installed and active, a set can include the service database, attached-document bytes, and public assets. This describes the backup design; it is not a promise that every deployment has activated or recently restored that job.

We keep your data for as long as your account is active. You can delete individual trips and their contents at any time in the app. To delete your entire account and the data you own, open your profile and choose account deletion. The recommended mode makes normal account use unavailable immediately and gives you seven days to restore the account before permanent deletion begins. You can instead choose immediate permanent deletion, which cannot be restored after confirmation. TripToad uses the same recorded deletion process for both modes and confirms completion only after checking the required steps here and with the services used for your account, except where we must retain data to comply with law or a documented safety boundary. The current process and a route for people who cannot sign in are explained on the account-deletion page.

Web first-touch attribution is stored with your account and remains there until the account is deleted. The browser copy and its sent marker remain in local storage until you clear TripToad’s site data. Product-use event records are configured to be deleted after 400 days. If an account or trip is deleted before then, its direct account or trip link is cleared from existing event records, while the event record can remain until that retention period ends.

Account-deletion completion verifies the required cleanup from TripToad’s live database, filesystem, object storage, and identity providers. Service backup copies have a separate boundary: the account-deletion process does not delete or verify those historical copies at the moment it completes. Those copies do expire. Private account data and private uploaded files may remain in disaster-recovery copies for at most 30 days after they are deleted from the live system, and the local backup cache keeps at most 14 days. A restore from an older copy does not undo a completed deletion: we keep a minimal record outside the ordinary database backup, and a restored account is held out of use until the deletion is applied again.

Content reports, generated-content suppression records, and their append-only operator audit entries also have a separate safety-record boundary. They are designed to survive deletion of the source account or trip so a report cannot erase its own evidence. A report can retain account or trip identifiers, its reason and optional details, and a bounded snapshot of the one reported item, but not a whole trip or discussion thread. A report is kept for at most 12 months after its case is closed, and is then deleted. An open case has no such limit, because the record is still in use. Deleting your account does not erase a report, but it does remove your direct identity from it: your name, email, and account references are removed and replaced with a correlation value that expires along with the report. Generated-content suppression records stay, because they are what stops removed content from being produced again; after deletion they contain no personal information.

Account-deletion workflow receipts also have a separate operational-record boundary. Append-only lifecycle and operator receipts retain the deletion-request identifier, state changes, selected blocker code, server-generated receipt identifiers, and a digest of the count-only plan an operator reviewed. Those receipts do not copy the user’s deletion reason, email address, or the underlying inventory into the audit record. TripToad does not currently publish an automatic expiry for these receipts; they require a separate approved retention or deletion process.

Selected trip-cover bytes can be cached as public image objects in Cloudflare R2. Replacing or removing a cover, or deleting its trip, attempts to remove the corresponding live cache object. That cleanup is best-effort: failed deletions and objects orphaned before this lifecycle existed have no scheduled reaper or fixed maximum age and can remain until an operator removes them.

Server process logs currently have no fixed maximum age in TripToad's repository or host configuration. They remain until an operator rotates or removes them. We are not describing them as automatically expired until a verified retention control exists.

You can access and edit your trip data in the app, revoke collaborator access, and delete content or request deletion of your account and associated data. Depending on where you live, you may have rights to access, correct, delete, or export your personal data, and to object to certain processing. To exercise these rights, contact us at the address below.

TripToad is intended only for adults age 18 or older, and we do not knowingly collect personal information from anyone under 18. TripToad does not currently collect a date of birth or identity document to verify age. If you believe someone under 18 has provided personal information, contact us at the address below.

We may update this policy from time to time. We will post the new version here and update the “Last updated” date above; material changes will be communicated in-app or by email where appropriate.

Questions about this policy or your data? Email us at [email protected].