Mapping your next journey
Legal document
Lawyer review required. This specific revision is awaiting recorded review completion.
This Cookie Notice explains how LeBo Travel B.V. uses cookies and similar technologies across lebotravel.com and related LeBo Travel web properties. It should be read with our Privacy Policy.
A cookie is a small text record stored by a browser and returned to a website. Similar technologies include local storage, session storage, service workers, Cache Storage, device or browser tokens, security challenges, and browser push subscriptions.
Some technologies are stored only for the browser session. Others remain until a stated expiry, until the purpose ends, or until you clear them.
Cookies normally contain a name, value, domain or host scope, path, expiry rule, and security attributes. First-party cookies are set for a LeBo Travel host; third-party technologies operate in another provider's environment or through a provider-controlled service. “Session” can mean that the browser removes the record when the session ends, although browser restore features may preserve a session longer than expected.
Local storage and Cache Storage are not automatically transmitted with every request, while cookies matching a request can be. HttpOnly cookies cannot ordinarily be read by page scripts. Secure and SameSite attributes reduce particular risks but do not make a credential safe to share. Browser push subscriptions and anti-abuse challenges are included because they can identify a browser installation even though they are not traditional cookies.
Technical classification considers where the value is stored, what component reads it, whether it is returned automatically, who controls the component, and whether it can single out a browser, session, account, or device. The same user-facing feature can involve several separate technologies with different security and legal characteristics.
Inventory records should identify the exact or patterned name, origin, provider, purpose, data elements, trigger, duration, access controls, and deletion method. Provider documentation is compared with observed behaviour because labels and default expiry periods can change between versions and configurations.
LeBo Travel currently uses technologies needed to:
We do not currently load advertising cookies, cross-site behavioural tracking, or third-party behavioural analytics on the public website. If we introduce an optional category that requires consent, we will update this Notice and provide a consent or preference mechanism before using it.
Our inventory is based on the technologies intentionally implemented in the current LeBo Travel product. Exact provider-generated names, split-cookie suffixes, expiry refreshes, and temporary security identifiers can vary by browser, environment, project, or provider configuration. Development and preview environments may also differ from production.
We classify a technology by its actual purpose rather than its label. A session identifier used to authenticate a requested account is necessary; the same type of identifier used to track unrelated browsing for advertising would not be. We periodically review code and providers so that the notice reflects material changes. The absence of behavioural advertising does not mean the site processes no technical information: hosting, security, and requested services still require ordinary network and device data.
The current approach is a product commitment tied to deployed behaviour, not merely a policy preference. Strict necessity is assessed for the function the user actively requests. Operational convenience, audience measurement, product curiosity, or possible future usefulness is not automatically sufficient to classify technology as necessary.
Release review compares new code, dependencies, embeds, provider dashboards, network requests, and browser storage against this Notice. A change that introduces an optional purpose is held behind the appropriate consent or preference control. Emergency security measures are documented and reassessed once the immediate risk ends.
Names can vary slightly where a provider splits a large cookie or includes an environment or project identifier.
| Cookie or pattern | Purpose | Typical duration |
|---|---|---|
sb-<project-ref>-auth-token and split variants |
Supabase customer or administrator authentication and session refresh | Browser session; deletion markers may be set on logout |
lebo_account_last_activity |
Enforces customer-account idle timeout | Browser session |
lebo_admin_last_activity |
Enforces administrator idle timeout | Browser session |
lebo_ledger_session |
Authenticates access to the private founder ledger | Up to 12 hours |
lebo_ledger_last_activity |
Enforces private-ledger idle timeout | Browser session |
lebo_order_session |
Gives a verified customer temporary access to matching orders | Up to 24 hours |
lebo_order_access |
Gives temporary access to a newly fulfilled order-received page | Up to 24 hours |
lebo_order_status |
Checks whether a newly paid order is ready and exchanges into order access | Up to 15 minutes |
lebot_session |
Maintains LeBot conversation continuity without exposing the conversation token to browser scripts | Up to 30 days |
lebot_order_session |
Maintains verified-order context inside LeBot | Up to 24 hours |
lebot_order_selection |
Remembers which verified order is selected inside LeBot | Up to 24 hours |
lebo_team_updates_session |
Authenticates the internal Team Updates workspace | Up to 30 days |
These cookies are used to provide a service requested by the user or protect the service. Blocking them may prevent login, order recovery, checkout return, private pages, LeBot continuity, or other essential functions from working.
Authentication cookies are issued only after the relevant sign-in or verification flow. They can be refreshed, rotated, split because of browser size limits, or replaced with deletion markers at logout. Order and quote cookies are scoped to temporary access and should not be treated as a permanent customer account. LeBot continuity cookies keep a conversation reference away from normal browser scripts but do not authorise unrelated account access.
The listed durations are upper limits or typical lifetimes. A cookie may end earlier because the user signs out, the server revokes the session, a security event occurs, the underlying order access expires, or the browser clears data. Conversely, a browser's restore behaviour can make a session cookie appear after reopening. On a shared device, sign out and clear site data where appropriate rather than relying only on closing a tab.
These cookies do not contain full payment-card details. Their values may nevertheless be security credentials. Do not copy them, paste them into support messages, or disclose them through screenshots or browser developer tools.
A strictly necessary cookie must have a direct role in authentication, session security, order or quote access, requested conversation continuity, payment return, fraud prevention, or another essential function described in the inventory. Its value and scope should be no broader than required for that function.
Issuance, refresh, rotation, revocation, logout deletion, idle timeout, and absolute expiry are tested. Sensitive cookie values use appropriate Secure, HttpOnly, SameSite, domain, and path attributes. Access credentials are invalidated server-side where deletion from one browser cannot reliably terminate the underlying authorisation.
| Cookie | Purpose | Typical duration |
|---|---|---|
lebo_ledger_locale |
Remembers the chosen language on the private ledger | Up to 1 year |
lebo_ledger_sync_range |
Remembers the private ledger's selected Outlook sync range | Up to 1 year |
lebo_ledger_sync_engine_version |
Detects whether a private-ledger sync cursor must be refreshed after a processing change | Up to 1 year |
lebo_ledger_sync_custom_start_date |
Remembers a selected custom private-ledger sync start date | Up to 1 year |
lebo_ledger_sync_custom_end_date |
Remembers a selected custom private-ledger sync end date | Up to 1 year |
These preferences are limited to private operational features. Removing them resets the relevant preference but does not normally affect public browsing.
Preference cookies remember a choice made inside a restricted operational feature so that the user does not need to select it on every visit. They do not by themselves create a public advertising profile. The private-ledger preferences concern presentation and synchronisation controls; access to the underlying ledger still requires its separate authentication.
Removing a preference may cause a default language, range, processing cursor, or date range to reappear. It does not erase source records stored on the server. A changed application version may deliberately ignore or replace an earlier preference where retaining it would produce an incorrect result. Preference duration can be renewed when the setting is used again.
Preference technologies preserve a user-selected presentation or workflow state but do not authorise unrelated profiling. A preference can be necessary to honour a requested setting without being essential to basic website delivery. The category is reassessed if the same value begins influencing marketing or cross-service decisions.
Preferences use understandable keys and bounded durations and can be reset through the relevant interface or browser controls. A version or schema change may invalidate an old preference. Server-side business records are not deleted merely because the local display preference controlling their presentation is removed.
Local storage remains on the device until the website or user removes it, browser data is cleared, or private-browsing rules delete it.
| Storage key or pattern | Purpose |
|---|---|
lebo-display-currency |
Remembers the selected display currency; checkout currency remains the currency shown at checkout |
lebo-payment-region |
Remembers the customer's payment-region selection so available payment methods can be ranked appropriately |
lebo-journey-token-v1 |
Stores a random browser credential that links intake drafts, quote or checkout steps, and order creation without placing the credential in a normal page URL |
| checkout-intent keys derived from a journey or quote | Prevent duplicate checkout creation and allow a user to start a fresh checkout after a conflict |
| travel-draft synchronisation state | Coordinates saved intake-draft revisions across tabs without storing the full server record in browser storage |
le-li-theme |
Remembers the light or dark theme on the founder site |
Journey and checkout credentials are random access tokens and should not be copied to another person. Clearing local storage may disconnect a browser from an unfinished draft or require a new checkout.
Local-storage keys are limited to the browser profile and origin that created them, but anyone with access to that browser profile may be able to inspect them. The journey token is a random bearer credential: it contains no readable itinerary, yet possession can reconnect the browser to the corresponding unfinished journey according to server-side rules. Reviewed quotes use a different, more temporary mechanism described in the next section.
Checkout-intent records are designed to prevent accidental duplicate creation and to recover from an interrupted return, not to prove that payment succeeded. The server and payment provider remain authoritative. Draft synchronisation metadata can include revision identifiers and tab-coordination state; the complete submitted intake remains server-side.
Clearing local storage resets the relevant browser continuity. It does not cancel a submitted request, paid order, provider booking, or charge. Contact us with the order reference if continuity is lost after payment.
Local storage is readable by scripts operating within the relevant origin, so security depends on preventing unauthorised scripts and limiting the value stored. Random bearer credentials can be sensitive even when they contain no readable personal data because possession may restore access to server-side state.
Keys are reviewed for necessity, entropy, content, namespace, cleanup trigger, cross-tab behaviour, and exposure to third-party scripts. Full intake records, payment details, identity documents, and privileged credentials should not be placed in local storage. Rotation and conflict handling prevent stale checkout or journey state from overriding authoritative server records.
Session storage is normally removed when the relevant browser tab or browsing session ends.
| Storage key or pattern | Purpose |
|---|---|
lebo-reviewed-quote-access-v1 |
Holds a private reviewed-quote access token after removing it from the URL fragment |
lebo:contact-prefill |
Temporarily transfers a customer-approved LeBot handoff summary into the contact form, then deletes it after use |
lebot_resume_human |
Returns a signed-in or verified customer to the requested human-support path |
| private-ledger scroll-position keys | Restores position when returning from a ledger expense detail page |
Session storage is isolated more narrowly than local storage and is normally associated with a tab. Opening, duplicating, restoring, or navigating tabs can behave differently between browsers. We use it for short-lived information that should not remain as a long-term device preference.
The reviewed-quote token is moved from a URL fragment into session storage so it is less likely to remain in copied addresses, server logs, or ordinary referrer data. It is still an access credential and should not be shared. The LeBot handoff summary is transferred only after the customer requests the handoff and is removed after the contact form consumes it.
Ending the tab can require the user to reopen an original valid link or request a replacement. Clearing session storage does not retract a message already submitted to LeBo Travel.
Session storage is selected where information should remain within a tab-oriented workflow and should not become a durable device preference. It reduces some persistence and sharing risks but does not protect against a person or script with access to the active tab and origin.
Private tokens are removed from navigable URLs before further use and are validated against expiry and server status. Handoff data is consumed once where designed. Tab closure, duplication, restore, browser crash, and back-forward navigation are tested so that loss or repetition does not create unauthorised access or duplicate actions.
In production, LeBo Travel registers a service worker that caches only a small public offline shell and public static assets. It is designed not to cache account, admin, order, checkout, delivery, API, or Team Updates traffic. Old LeBo public-shell caches are removed when a new service-worker version activates.
The service worker may also display a browser notification after you explicitly enable Web Push. Notification messages are designed not to include customer conversation text.
You can remove service workers and cached data through browser site-data settings. Doing so disables offline public assets until the website registers and fills the cache again.
A service worker is a browser script that can respond to requests and notifications in the background within its registered scope. The production worker uses an explicit public-shell allowlist and excludes sensitive route families. Network and response controls provide additional protection, but users should still sign out and avoid retaining sensitive pages on a shared device.
Cache Storage can contain HTML for the approved offline page and versioned public assets such as scripts, styles, icons, or fonts. Cached public information may be older than the live site until refreshed. It must not be relied on for current entry rules, price, availability, emergency information, or other time-sensitive decisions.
Unregistering the worker and deleting caches removes offline capability and push handling for that browser until re-enabled. It does not delete server-side accounts, conversations, orders, or push records already queued for revocation.
Service-worker scope and caching rules are security boundaries. Public offline convenience must not capture authenticated, personalised, transaction, API, admin, delivery, or no-store responses. Cache versioning also determines when corrected or time-sensitive public information replaces an older offline copy.
The worker uses explicit route and response checks, controlled asset lists, cache names, activation cleanup, and failure handling. Release testing inspects Cache Storage and offline behaviour. A security or content issue can require immediate cache-version change, worker update, or removal of an asset from offline availability.
Web Push is off by default. If you choose to enable it, the browser creates a subscription containing a push-service endpoint and public encryption keys. LeBo Travel stores the subscription so the browser's push service can deliver a privacy-limited notification.
The push service may be operated by the browser or operating-system provider. You can disable notifications in the LeBo Travel account controls or browser settings. We revoke subscriptions when you disable them, when the related session is revoked, or when repeated provider failures show that the subscription is no longer usable.
Permission is requested through the browser only after a user action in a supported feature. The operating system or browser may remember a grant or denial and may suppress repeated prompts. LeBo Travel cannot override those controls. Enabling notifications for one browser profile does not automatically enable another device.
A subscription endpoint is effectively an address assigned by the browser's push service, accompanied by encryption keys used to protect payload delivery. We associate it with the relevant authorised context and store status, creation, and failure information needed to manage delivery. Notification content is deliberately limited; opening it may require fresh account or order verification.
Delivery is best-effort. Power settings, browser policy, network conditions, provider outages, expired subscriptions, and revoked sessions can prevent or delay a notification. Essential service information may therefore also be sent through another agreed channel.
Push permission, subscription creation, server association, notification delivery, and opening a notification are separate events. Permission granted to the browser does not authorise unlimited topics or sensitive message content. A subscription endpoint is treated as a revocable delivery credential.
Opt-in is recorded against the feature and authorised session. Payloads are minimised and encrypted by the push protocol, and sensitive conversation details are not placed on the lock screen. Disablement, account or session revocation, provider expiry, and repeated delivery failure trigger removal or deactivation of the subscription.
Public forms, login, order verification, and LeBot may use Cloudflare Turnstile or related security signals to distinguish legitimate use from automated abuse. Turnstile may process browser, device, IP, interaction, and challenge information and may store or access a strictly necessary identifier under Cloudflare's rules.
This security processing is used only where needed to protect a form or feature. Blocking it may prevent the protected request from being submitted.
Turnstile can run a browser challenge, assess technical and interaction signals, and return a server-verifiable token indicating whether the protected request may proceed. The token is short-lived and tied to the security purpose; it is not a substitute for customer authentication or proof that submitted information is accurate.
The challenge can differ depending on risk and browser capability. Privacy tools, blocked scripts, disabled cookies, unusual networks, or automated browsing may prevent completion. Where feasible, contact us if an accessibility or technical issue blocks a genuine request, but we do not bypass protection in a way that would expose the service to abuse.
Security logs may record success, failure, timing, IP-derived signals, and request identifiers so attacks and false positives can be investigated.
Anti-abuse technology is deployed where the risk to forms, accounts, orders, public APIs, or LeBot justifies browser and network assessment. The challenge result is one security signal and is not proof of identity, contractual authority, payment validity, or truthfulness of the submitted content.
Protected routes, token lifetime, server verification, failure response, accessibility fallback, and provider data flow are documented. Challenge logs are retained only as needed for attack analysis, false-positive review, and system integrity. A bypass is not granted solely because a user blocks the required security technology.
When you choose to pay, we create a secure checkout session and redirect you to Stripe. Stripe operates its checkout pages under its own cookie and privacy notices and may use cookies or similar technologies for payment, fraud prevention, authentication, security, and remembering checkout choices.
Stripe's technologies are primarily used on Stripe-controlled pages or frames. Blocking them may prevent payment from working. LeBo Travel receives transaction references and payment status, not full card details.
Before redirecting, LeBo Travel creates a provider checkout associated with the selected catalog item or accepted quote, amount, currency, and internal payment attempt. Stripe then determines which payment, authentication, fraud, and checkout technologies are necessary in its controlled environment. Its cookie names and durations are not part of LeBo Travel's first-party inventory and can change independently.
Returning from Stripe does not by itself prove payment. Our server reconciles signed provider events and transaction state before an order is treated as paid. A checkout session can expire, and opening multiple sessions may create confusion even when duplicate charging protections exist. Use the order-status path or contact us instead of repeatedly paying.
Stripe may receive network, device, transaction, payer, and authentication information under its own notices and legal roles.
Stripe controls technologies used in its hosted checkout and payment-security environment, while LeBo Travel controls the creation of the intended checkout, internal payment reference, and processing of authenticated return and webhook events. These roles and environments must not be conflated.
Checkout creation is linked to server-authoritative product, amount, currency, and mode. Return pages do not independently mark payment successful. Signed provider events, idempotency, reconciliation, expiry, refunds, and disputes are processed against transaction records. Customers review Stripe's current notice for provider-controlled cookies.
Supabase provides authentication and database services. Authentication cookies are strictly necessary to keep a signed-in customer or administrator authenticated and to refresh the session securely. LeBo Travel converts normal persistent authentication cookies into browser-session cookies except when deleting them, reducing how long authentication remains on a shared device.
Supabase authentication can use several cookies because a signed session may be divided into chunks. The project reference in the name identifies the relevant Supabase project, not the individual user. LeBo Travel applies cookie attributes and session-lifecycle controls around the provider session and clears matching cookies when an account becomes inactive or the user signs out.
Authentication storage is distinct from the application records held in the database. Deleting a browser cookie ends or disrupts local access but does not erase an account, order, intake, invoice, or conversation. Conversely, revoking a server-side session can make an apparently present browser cookie unusable.
Database requests made by our server do not require a public browser to receive privileged service credentials. Those credentials are kept outside page code.
Supabase authentication storage represents a signed session and can be divided into multiple cookie chunks for technical reasons. The cookie pattern does not describe all database processing, and database records remain governed by the Privacy Policy even when the browser session is removed.
Cookie handling applies secure attributes, refresh logic, browser-session conversion where configured, idle and device-session controls, and deletion markers. Public clients receive only intended public configuration. Service-role credentials remain server-side and are never placed in cookies, local storage, page source, or browser-delivered bundles.
LeBot requests are sent from our server to configured AI infrastructure. The browser does not receive an AI-provider credential. The LeBot session cookie is first-party and HttpOnly. Provider-side logs and request identifiers are governed by the applicable provider configuration and our Privacy Policy; they are not advertising cookies placed by the LeBo Travel public page.
The browser sends a LeBot request to LeBo Travel, and our server decides what limited conversation, page, language, account, or verified-order context can be forwarded. Gateway and model providers may create their own server-side request logs or identifiers according to contract and configuration. This is different from placing a third-party advertising cookie in the user's browser.
The LeBot cookie supports continuity and abuse controls. Removing it can start a new conversation or require verification again, but does not necessarily delete prior server records. AI infrastructure may change without changing the first-party cookie name; a material change to provider category or browser technology will be reflected in the Privacy Policy or this Notice as appropriate.
LeBot browser storage supports LeBo Travel's conversation and verification boundary, while gateway or model logging occurs server-side under provider configuration. A change in model provider may alter recipient or transfer information without necessarily introducing a new browser cookie.
The session cookie is protected from ordinary page-script access and mapped to server-side records. Verified order context uses separate, shorter-lived authorisation. Provider credentials and unrestricted account data are not exposed to the browser. Privacy and vendor assessments are updated when AI infrastructure or data flows materially change.
Clicking a link to a social network, map, booking site, provider, or other external service opens that party's environment. The third party may then use cookies or tracking under its own notice. A simple external link does not allow that party to set a cookie through LeBo Travel before you open it.
Where a future feature embeds a third-party tool, we will assess whether consent or an additional notice is required.
An ordinary hyperlink does not load the destination's scripts, pixels, or cookies into the LeBo Travel page before it is opened. After the click, the destination receives the technical information inherent in a new web request and may recognise an existing account or cookie. Opening in a new tab does not prevent that processing.
Some future features, such as embedded maps, videos, calendars, reviews, or support widgets, could transmit information before a deliberate visit to the provider. We will prefer privacy-preserving patterns, assess whether the feature is necessary or optional, and implement consent where applicable. A screenshot or static preview may be used instead of a live embed where it meets the purpose.
Links may contain service or campaign parameters. Do not share a URL if it contains a private quote, order, or access credential.
External technology risk depends on whether the third party is loaded automatically, only after an affirmative click, or within a controlled embed. The presence of an external brand or link alone does not establish that its trackers ran on the LeBo Travel page.
Embeds are reviewed for network calls, cookies, identifiers, referrer, account recognition, consent mode, and privacy-preserving alternatives. Optional content can use click-to-load or static previews. Private order and quote parameters are excluded from public links, embeds, social metadata, analytics, and search indexing.
You can:
Blocking strictly necessary technology can stop account, order, checkout, form, quote, LeBot, and private-workspace features from operating. Browser settings differ, so consult the browser provider's help pages for exact instructions.
Browser controls may allow blocking all cookies, blocking third-party cookies, deleting data for one site, clearing data at exit, managing notification permission, or viewing individual storage records. The labels and effects vary. A browser extension can also interfere with scripts or network requests in ways that are not visible in the standard cookie list.
To fully reset local LeBo Travel state, a user may need to sign out, disable notifications, clear cookies and site storage, unregister the service worker, and close related tabs. This is broader than ordinarily necessary and can make unfinished drafts, quote access, and order recovery unavailable from that browser. It does not cancel financial or contractual obligations.
For a suspected stolen device or credential, use account revocation or contact us; local deletion on a different device will not secure the lost browser.
User control includes feature-level controls, browser storage deletion, notification permission, account sign-out, session revocation, and avoidance of optional providers. Each control has a different effect. Clearing one key may not revoke server access, while server revocation can invalidate a key that remains visible locally.
Instructions should explain the likely functional consequence and avoid requiring users to expose credential values. For security incidents, account or device revocation is preferred over relying solely on local deletion. Browser-specific steps are provided by the browser vendor because menu names and storage grouping change.
Where applicable law permits, strictly necessary cookies and similar technologies are used because they are required to provide a service requested by the user, secure communications, prevent fraud, or maintain essential website operation. Preference storage is used for the requested setting or our legitimate interest in preserving a low-risk user choice.
If we add analytics, advertising, personalisation, or another non-essential technology that requires consent, we will request consent before setting or accessing it and provide a way to change that choice.
Under EU and similar rules, storing or accessing information on a device can require consent unless it is strictly necessary for the user-requested service or qualifying communications function. Separately, processing personal data produced by the technology requires a basis under the Privacy Policy. These are related but distinct legal questions.
Necessity is assessed by function. Authentication, fraud prevention, transaction continuity, a requested preference, and opted-in push delivery can have different justifications. We do not classify a technology as necessary merely because it is useful to LeBo Travel. If an optional technology is introduced, refusal must be respected without setting it first, except for a limited mechanism needed to remember the refusal where permitted.
Consent, when required, will be specific enough to make the category and purpose understandable and can be changed for future use.
The ePrivacy-style device-access rule and GDPR personal-data rule are analysed separately and cumulatively where applicable. A technology can be exempt from consent because it is strictly necessary while the resulting personal-data processing still requires transparency, purpose limitation, security, retention, and a valid GDPR basis.
The assessment records purpose, user request, technical necessity, less intrusive alternatives, category, legal basis, default state, consent signal if required, withdrawal, and downstream data use. Consent is not bundled with an essential service where the optional technology is not needed to provide that service.
We update this Notice when our website technology, providers, cookie names, or retention periods materially change. The "Last updated" date identifies the current inventory. You can contact hello@lebotravel.com with questions about a technology listed here.
We review this inventory when authentication, checkout, account security, order access, LeBot, push delivery, service-worker caching, preferences, or third-party integrations change. A small provider-generated name variation may be covered by an existing pattern, while a new purpose or category requires substantive notice.
The effective date helps users compare versions. Material optional technologies will not be justified solely by updating the text after deployment; the appropriate consent or control must exist when required. Earlier revisions remain in our managed-content history, and each new legal revision reopens the internal lawyer-review indication until an authorised administrator confirms review. Questions can identify the browser, feature, and approximate date without sending raw credential values.
Notice maintenance is triggered by changes in purpose, technology, provider, cookie pattern, duration, security design, consent classification, or user control. Minor generated suffixes can remain within a documented pattern, but a new function cannot be hidden under an old name.
A release owner reconciles the technical inventory, canonical Markdown, database revision, publication date, and lawyer-review state. Material optional technology is not activated before required controls exist. Historical versions remain available internally to establish what was disclosed when a particular technology was in use.
