Privacy policy

Viamente is an AI travel planner built by Lygge Studios ApS, based in Copenhagen, Denmark. Questions about this policy or your data: use the contact form.

Viamente stores the travel plans and flight-research threads you create and the messages you exchange with its assistants. You can also collaborate inside the app and choose to publish a revocable, unlisted, read-only link to a limited view of a journey. This policy covers those features and the additional capabilities — such as bookings and a mobile companion — as they ship.

• Account — your email address, an optional display name, and the identifiers we receive when you sign in via magic link or Google. A session cookie (viamente_session, HttpOnly) keeps you logged in.
• Plans, research, and conversations — the trip plans you create (destinations, dates, accommodation choices, notes), the flight-research threads you start, and the messages you send to our assistants. Your messages, together with the relevant profile context, are transmitted to our AI providers to interpret requests and generate replies (see §4).
• Connected calendars — if you connect Google Calendar, we receive your Google account identifier and email, store the refresh token encrypted, create a separate “Viamente Journeys” calendar, and write only the Journeys you switch on. With read-only consent, we also retrieve the names and colours of calendars visible to you and live event titles, locations, times, and busy/free state for the date window currently shown or planned. We do not retrieve descriptions, attendees, or meeting details, and we do not store personal event history in Viamente. Relevant Journey-window events may be sent to our AI provider so Menta can identify overlaps and plan around them. We never write into your existing calendars. If you create a calendar subscription, its unguessable feed URL acts like a password: anyone who has it can read the Journey dates, titles, locations, and details you selected until you replace or revoke the URL. Calendar exports are optional and can be disabled per Journey.
• Public journey links — when a journey owner creates an unlisted share link, anyone who has that link can read the allowlisted journey summary until the owner revokes it. The shared view can include the journey title and dates, route and stops, itinerary, selected or saved travel options, prices or budget when the owner chooses to include them, and traveler initials with broad adult or child labels. It does not include assistant conversations, notes, full traveler names, contact or account identifiers, loyalty details, or booking confirmation codes. Opening the link does not disclose a visitor's account identity to the journey owner; copying it into a new editable journey requires the visitor to sign in.
• Profile context — your durable travel profile and traveler roster: preferences the assistant infers from your conversations (e.g. "travels with kids", "prefers boutique stays"), the people you add as travelers (names and relationships), and — only where you choose to provide them — details such as citizenship, loyalty-program numbers, and seating or dietary preferences. This is what makes subsequent plans smarter for you specifically. You can ask for the contents of this profile or its deletion at any time (see §6).
• Raw planning input — the verbatim text you type during onboarding and to the assistant is also kept as an internal record so we can improve how the assistant understands trips and preferences. It is never shown to other users and is deleted with your account.
• Bookings — when you book a hotel or flight through Viamente, the booking details, including the traveler details you enter for it, are shared with the travel supplier fulfilling that booking (see §4).
• Diagnostics — server logs (HTTP method, path, status code) are retained for roughly 30 days for debugging and abuse prevention. The bearer token in a public journey path is replaced with a redacted placeholder before that path is written to structured application logs.
• Maps and location searches — public country and local-guide pages load a static map image from Google Maps Platform, while public journey views load basemap tiles, labels, and map assets from OpenFreeMap. Those direct browser requests give the provider ordinary connection data such as your IP address and browser details. Public journey requests contain the map area needed for the view but not the secret share-link token. Google guide requests contain only the guide's public place names and coordinates, never your account or plan data. When you use location search, place details, geocoding, or route tools in the app, we send the place text, coordinates, or route endpoints needed to answer that request to Google Maps Platform.
• Error-recovery reports — when an error or map recovery screen lets you flag a bug, we collect the note and optional screenshot you submit together with the app route, browser and viewport details, error details, and a timestamped link to a session replay when available. Screenshots are optional and can be removed before submission.
• Acquisition and product analytics — page paths, standard campaign parameters (utm_source, utm_medium, utm_campaign, utm_content, and utm_term), the external referring domain, landing path, device type, and product actions. We keep bounded first- and latest-touch attribution in your browser for up to 90 days after your last visit so a campaign can still be connected after a landing-page CTA or sign-in link removes its query string. A passive page view remains in PostHog only. If you deliberately use a planning or sign-in call to action, or open the Messenger, we create a limited pseudonymous Lead in our internal CRM using a random browser ID and this bounded context. For that Lead, we also retain the first and latest coarse city, region, country, and timezone Cloudflare inferred when serving the request. Later page presence may refresh an existing Lead's latest attribution and coarse location, but never creates a Lead by itself. We do not add the visitor's IP address, precise coordinates, postal code, raw user-agent string, or full referring URL to that Lead. When you sign in, the Lead is merged into your account contact and the context is added to your PostHog person profile and Intercom support contact. On a public journey view, ordinary page analytics can record a redacted route, but never the share-link bearer token; session replay is disabled there.
• Support conversations — when you open the Intercom Messenger on a public page, Intercom assigns an anonymous browser identifier and uses support-session cookies and local storage to keep the conversation available as you navigate. We also give that visitor the bounded attribution and device context described above. After sign-in, we additionally send your Viamente user identifier, name, email address, account creation date, and the current plan ID as support context. The current in-app URL is refreshed in Intercom as you navigate. If you attach a screenshot or file in the Messenger, it is sent to Intercom with that conversation. During an administrator's demo or read-only app view, Intercom is shut down and no support identity is created for the viewed account. An administrator's own app view behaves like their ordinary signed-in session. The Messenger is also disabled on public journey views, so the share-link bearer token and shared journey are not sent to Intercom.

• Cloudflare, Inc. — Workers, D1 (SQLite), and Email Sending (outbound transactional email such as magic links). Cloudflare is our primary processor; data is stored in EU regions where Cloudflare supports it.
• PostHog Cloud EU (eu.i.posthog.com) — page and product analytics across public and signed-in customer pages, including campaign, referring-domain, landing-path, and device-type context. Session replay is limited to signed-in app sessions. Replays record rendered text, all form values (including password-type fields), and canvas content such as maps without general masking. Security-sensitive bearer values, including private calendar subscription links, are excluded. Console logs, request headers, and request or response bodies are not recorded. Replays begin only after sign-in and stop on logout. PostHog cookies (prefixed ph_) are first-party and used to stitch a single visitor's session together. Your distinct ID is bound to your Viamente user ID only after you sign in. Demo and read-only administrator app views are excluded from PostHog identification and session replay; an administrator's own app view behaves like their ordinary signed-in session. Public journey views can emit ordinary page and product analytics under a redacted route such as /share/[redacted], but the share-link bearer token is removed and session replay stays disabled even for a signed-in visitor. Automatic element capture is disabled inside public journey views; only explicit redacted product events are sent.
• Intercom, Inc. — the in-app support messenger. Our Viamente workspaces use Intercom's US data region. On public pages, the Messenger starts without account attributes and uses an anonymous browser identifier plus the bounded campaign, referring-domain, landing-path, and device-type context described in §3. After sign-in, we send the same context with your Viamente user identifier, name, email address, account creation date, and current plan ID so Intercom can attach support conversations to your account. Any screenshot or file you choose to attach is sent with that conversation. The Messenger is shut down during demo and read-only administrator app views and on public journey views.
• Google Cloud (Vertex AI) — large-language-model inference for the planning assistant, Flight Research, attachment transcription, booking-document understanding, and internal structured extraction. The content needed for each feature — such as conversation or research messages, relevant profile context, and files you ask us to interpret — is transmitted to Google Vertex AI through Cloudflare's AI Gateway. Google does not originate or price the flight offers shown by Viamente.
• Google Maps Platform — static map images on public destination guides, and place search, place details, geocoding, and route calculations used by planning tools. Public guide images are requested directly by your browser from Google; the guide request contains only public destination data. App location requests send only the search text, coordinates, or route endpoints needed to provide the feature.
• OpenFreeMap — basemap tiles, labels, and map assets displayed in public journey views. These assets are requested directly by your browser using the visible map area; the secret share-link token is not sent with those requests.
• Google LLC (sign-in) — only if you choose “Continue with Google” to sign in. We request the openid email profile scopes solely to look up or create your Viamente account and to show your name and email in the app.
• Google LLC (connected calendars) — only if you separately connect Google Calendar. We request calendar.app.created, calendar.calendarlist.readonly, calendar.events.readonly, openid, and email. This lets Viamente create and manage its own secondary calendar, list calendars visible to the account, read bounded event windows, and identify the connected account. The read scopes do not let us change existing calendars. Selected Journey dates, titles, locations, notes, and Viamente links are sent to Google as private events. Disconnecting deletes the Viamente-created calendar and revokes the grant.
• Google Calendar and Google Meet (booking page) — only if you choose the 20-minute booking link. Google hosts the booking page and handles the appointment and any Meet details. This is separate from the optional calendar export above.
• LiteAPI and the fulfilling travel supplier — only when you make a booking. The booking details and the traveler details you enter for it are passed to the booking platform and the hotel or airline that fulfils the booking; from that point they also process the data as required to deliver the service you booked.
• Stripe, Inc. — payment processing for paid memberships. Checkout and the billing portal are Stripe-hosted pages; we store no card data ourselves. On our side we keep only a Stripe customer reference and your membership record: tier, subscription status, current allowance-period bounds, and the yearly price you locked in. Stripe holds the payment records, including invoices we are required to retain under Danish bookkeeping law.

• viamente_session — essential, HttpOnly, keeps you signed in.
• viamente_calendar_oauth_* — essential, HttpOnly, and kept for at most ten minutes while you complete the separate Google Calendar connection.
• ph_* — set by PostHog for analytics (see §4).
• intercom-* — support-session cookies and local storage used by Intercom across supported public and signed-in pages (see §4). The Messenger does not run on a public journey view.
• vmt_marketing_attribution_v1 — first- and latest-touch campaign, referring-domain, landing-path, and device-type context in local storage. It expires 90 days after the last customer-page visit.

We do not set advertising cookies. Intercom support cookies and local storage keep the Messenger available across public and signed-in pages. Visitors in the EU / EEA / UK / Switzerland see a banner explaining these practices. Accepting it stores a single acknowledgement in your browser's local storage.

Your journeys persist until you permanently erase them or delete your account. Cancellation or downgrade does not remove a retained journey: it remains readable and editable, and editing it does not create a new allowance entry. Journey erasure permanently removes its Viamente-owned structure, conversation, notes, files, and saved reservation copies. It cannot be undone and does not cancel a reservation held by an airline, hotel, or other provider.

Calendar connections and subscription tokens persist until you disconnect, revoke them, or delete your account. Personal Google event history is read live for the requested planning window and is not retained in Viamente's database or conversation history. Disconnecting Google Calendar deletes the dedicated Viamente calendar before revoking its grant; revoking a subscription URL makes that URL stop working immediately. Copies already written into an external calendar are also held by that calendar provider. To ensure those copies are removed, use Disconnect before deleting your Viamente account, or delete them in the external calendar.

An unlisted journey link remains usable until its owner revokes it or the underlying journey or account is deleted. Revocation makes the public view unavailable immediately. The minimal share-link record and its revoked status remain with the journey until that journey is erased, so the same bearer link cannot become active again by accident.

Bug-report screenshots and diagnostic evidence are retained while the report is under review and are accessible only to Viamente administrators. Account deletion removes those screenshots and report evidence, deletes associated PostHog recordings, and removes replay links from retained roadmap records.

Intercom support profiles and conversations are held by Intercom and follow its retention and deletion controls, including for files you attach there. Account deletion stops future identification in Viamente; contact us if you want us to forward an erasure request for support data.

To erase your entire account and all associated data, open Account, choose “Delete account”, and complete the three confirmation steps. We first email you a permanent record of what will be removed, including your flight and hotel reservation history. After you confirm that record, we send a separate six-digit deletion code. Email contact form if you cannot use the self-service flow. Erasure normally completes within minutes and is retried automatically if a processor is unavailable. Erasure removes:

• Your plans, messages, and profile context from our database;
• Your PostHog person profile and all associated events;
• Bug-report screenshots, evidence, and session recordings;
• Any session, magic-link, or API tokens tied to your account;
• Your users row, after the cascading deletes above.

What survives an erasure. We do not retain a hidden identifier to carry journey usage into a later account. Records we are legally required to keep — such as invoices under Danish bookkeeping law, held at our payment processor — are retained for their statutory period. External booking providers separately keep the records they need to deliver and account for reservations.

Account deletion ends a paid membership immediately. It does not cancel hotel or flight reservations: the booking platform, hotel, airline, and other fulfilling suppliers retain the records they need to deliver and account for those services. The first deletion email is your copy of their confirmation details before Viamente removes its local booking records.

Logging out calls posthog.reset() and shuts down the identified Intercom session so subsequent activity on the same browser is not associated with your account. The public Messenger may then start a separate anonymous visitor session.

Under the GDPR and equivalent data-protection laws, you have the right to access, rectify, erase, restrict the processing of, port, and object to the processing of your personal data. Write to contact form and we will respond within 30 days. You also have the right to lodge a complaint with your local data-protection supervisory authority.

Viamente is not directed at children under 16 and we do not knowingly collect personal data from them.

Cloudflare, PostHog, Google, and Intercom are US-headquartered companies. We use EU infrastructure where the configured service supports it; Vertex AI requests may be processed outside the EEA. Our Viamente workspaces use Intercom's US data region, so support conversations and user-attached files may be processed and stored in the United States. Where transfers outside the EEA occur, they rely on the EU Standard Contractual Clauses or an equivalent transfer mechanism.

We will update this page when our practices change. Material changes will re-prompt the cookie notice in your browser so you see them on your next visit.