Privacy Policy

Collected from Garmin: When you connect Garmin, Quantified Self can import Garmin activities, request Garmin history imports, request Garmin sleep history, and receive Garmin health/sleep updates when Garmin permissions allow it.

Stored and used in Quantified Self: Imported Garmin data is used to build your dashboard, event analysis, sleep views, and related summaries. When needed, Quantified Self may retain original activity files or equivalent source-file metadata for downloads, exports, reprocessing, and syncing past activities.

Shared with Garmin: You can send a saved route or explicitly select a GPX/FIT route file in Garmin Services. Quantified Self parses the selected route and creates a Garmin Connect course. Direct selected-file delivery does not create or retain a Quantified Self route or Garmin delivery metadata.

Shared with Suunto from Garmin: If you turn on automatic Garmin to Suunto activity sync or choose to sync past activities, Quantified Self uses the original activity file already saved with the Quantified Self event to send that activity to Suunto. That workflow therefore involves both Garmin-originated data and Suunto as a destination processor.

Collected from Suunto: When you connect Suunto, Quantified Self can import Suunto activities and history, sync recent sleep data, import sleep history, and automatically import new or updated Suunto routes into your saved Routes list.

Stored and used in Quantified Self: Imported Suunto data is used for event analysis, route detail views, dashboard summaries, sleep views, and saved route management. Connection metadata and processing metadata are also stored so reconnect, dedupe, and refresh workflows can work reliably.

Shared back to Suunto: When you upload FIT activities or send a saved or selected GPX/FIT route to Suunto, Quantified Self sends the file or generated GPX route needed for that upload. Suunto receives GPX routes, so selected FIT routes and saved routes are converted to a compatible GPX route in memory; saved routes use the Quantified Self route name. Direct selected-file route delivery does not create or retain a Quantified Self route.

Account-scope note: Routes imported from one Suunto account are blocked from being sent back to that same account, but can still be sent to a different connected Suunto account when that workflow is available to you.

Collected from COROS: When you connect COROS, Quantified Self can import recent COROS history, sync recent COROS sleep summaries, and import activities for event analysis and dashboard use.

Stored and used in Quantified Self: Imported COROS activities and summaries are used for dashboard metrics, event analysis, and provider-specific history tooling. Quantified Self may retain original activity files or equivalent source-file metadata when later downloads, exports, reprocessing, or sync tools depend on them.

Shared back to COROS: When you upload a FIT activity to COROS, Quantified Self sends the selected FIT file to COROS.

Shared with Suunto from COROS: If you turn on automatic COROS to Suunto activity sync or choose to sync past activities, Quantified Self uses the original activity file already saved with the imported Quantified Self event to send that activity to Suunto. That workflow therefore involves both COROS-originated data and Suunto as a destination processor.

Collected from Wahoo: When you connect Wahoo, Quantified Self can receive completed workout-summary webhooks and request Wahoo workout history. Only workouts with an available FIT file are imported, and records identified by Wahoo as originating from third-party fitness applications are skipped.

Stored and used in Quantified Self: Imported Wahoo FIT activities, source identifiers, summary revision metadata, and original activity files are used for event analysis, dashboard metrics, exports, deduplication, and reprocessing. OAuth credentials are stored server-side and are not readable by the browser.

Disconnect and retention: Disconnecting Wahoo revokes future provider access and stops new imports. Activities already imported into Quantified Self are retained until you delete those activities or delete your account. Account deletion removes Wahoo tokens, provider mappings, queue state, and imported account data under the normal deletion workflow.

Shared with Wahoo: You can explicitly send a selected FIT activity file or GPX/FIT course/route file directly to Wahoo, turn on/send a date range for Garmin, COROS, or Suunto activities already stored in Quantified Self, or opt in to automatic/backfill delivery of Suunto routes already saved in Quantified Self. Quantified Self converts selected GPX routes to FIT in memory before sending them to Wahoo, and converts saved Suunto routes to FIT in memory for the same destination. Saved-route delivery uses an opaque stable key so an updated saved route updates the same Wahoo route. Direct Wahoo activity delivery does not create or retain a Quantified Self activity; direct course/route delivery does not create or retain a Quantified Self route.

Shared with Suunto: You can turn on or backfill Wahoo-to-Suunto activity sync. Quantified Self sends the retained original FIT file from a Wahoo-imported event to Suunto only after you enable or start that route.

Outbound boundaries: Wahoo-to-Suunto is the only Wahoo-origin provider-to-provider activity route. Suunto-to-Wahoo saved-route delivery is a separate opt-in route workflow in Suunto Services; direct GPX/FIT course/route delivery is a separate Wahoo-only upload. Plans, sleep, and other non-activity data are not sent between Wahoo and another provider. Existing Wahoo connections may need to be reconnected to grant workout and route access for delivery to Wahoo.

User-authorized access: An MCP client receives data only after you sign in to Quantified Self and approve one or more requested read-only permissions. Activity locations depend on activity details, and saved-route locations depend on saved-route summaries. Removing a parent permission also removes its location permission. The client cannot use MCP to write activities, routes, settings, Training state, body measurements, or sleep records.

Metric permission: This access can return numeric metrics already stored for your activities and ready server-derived Training snapshots. When individual activity access is also granted, a client can request up to 25 explicitly selected canonical numeric Sports Lib metrics for one referenced activity. Quantified Self excludes precise latitude/longitude and first-class body-measurement metrics, and removes event/activity identifiers, names, labels, source fingerprints, and imported device/provider source keys from Training payloads.

Body-measurement permission: This separate access can return bounded body-measurement history. Body-weight history is returned only as identity-free day, week, or month values for a range of at most 366 days; exact source measurement timestamps, event/activity identity, names, provider/device metadata, and source provenance are excluded.

Activity-type catalog: Any authorized MCP client can discover canonical Sports Lib activity types for route and activity filters. This static catalog contains no account data. Activity-detail permission: Individual activity access can return non-location summaries, laps, swim lengths, MTB jump measurements, selected persisted numeric metrics, signed-in application links, and bounded chart-ready streams. It can filter bounded newest-first scans by those types and resolve today or yesterday only with an explicit IANA timezone. A chart request temporarily reads and selectively parses an existing original FIT, GPX, TCX, Suunto JSON/SML, or gzip file, downsamples the complete activity, discards parsed objects, and does not create a reparse, backfill, cache, or additional activity record. Historical charts depend on the original source remaining available and within processing limits.

Activity-location permission: This dependent permission can add exact activity start/end and MTB jump coordinates, enable nearby-activity searches, and return a bounded breadcrumb trace with an activity chart. Without it, activity summaries and jump measurements remain available with coordinates omitted, and explicit location requests are rejected before location or source work begins. Exact activity locations can reveal a home, workplace, frequent trailhead, or other sensitive place.

Sleep permission: Sleep access can return normalized session summaries, day/week/month aggregates, bounded discovery of recorded safe aggregate vital types, and a one-call sleep trend that combines coverage with duration, score, stages, HRV, heart-rate, blood-oxygen, and respiration values for a requested period. Raw samples remain excluded, and recorded values cannot diagnose illness. When Activity and Training metrics are also approved, the client can request the same live UTC-day Readiness used by Dashboard Today. That result combines current Form/ramp with the latest eligible sleep score and can return safe aggregate latest HRV and sleep-heart-rate values, same-provider baseline medians, ratios, evidence counts, and explicit missing or insufficient-baseline states. The requested IANA timezone supplies local-day context; it does not change the UTC scoring boundary. The preferred daily report returns the latest completed non-nap sleep with recorded average/overnight HRV and average/minimum sleep heart rate, a same-provider duration comparison, live Readiness, and current-versus-usual equivalent 28-day Training totals and Running/Cycling/Swimming mix. The older compact briefing remains physiology-free for compatibility. These projections exclude provider identity, provider user and session identifiers, provider-specific payloads, raw sleep-stage intervals, score components, raw HRV samples, SpO2 and respiration samples, locations, activities, body measurements, workout plans, and medical advice.

Saved-route summary permission: Saved-route access can return route names, activity types, bounded metrics, route/waypoint/point counts, import/update times, and signed-in application links. It can filter a bounded newest-first scan by canonical Sports Lib activity type or a case-insensitive part of the route name. It omits exact bounds, preview geometry, and waypoint locations.

Saved-route location permission: This dependent permission can add exact geographic bounds, simplified polyline preview geometry and segment endpoints, nearby-route search, and waypoint coordinates, altitude, and distance. Existing clients retain non-location route summaries but must reconnect and approve this permission to regain coordinate-bearing route tools. Activity and saved-route location permissions are independent.

Projection exclusions: Original files, full-resolution recordings, absolute per-sample timestamps, unrequested streams, separate internal identifiers, source keys, Storage paths, parser extensions, provider/device provenance, waypoint names/comments, links, and delivery metadata are not returned.

Place-name resolution: Nearby MCP searches can use direct latitude/longitude or a place name. Direct-coordinate searches are processed within Quantified Self. For a place-name search, Quantified Self sends only the location text to Mapbox for forward geocoding; activity data, route data, account identifiers, and unrelated client prompts are not sent to Mapbox for that lookup.

Credentials and retention: MCP bearer and refresh credentials are opaque, stored server-side only as hashes, expire automatically, and are bound to your account and the MCP resource. Approving a request creates pending authorization metadata, but a new connection becomes active and appears in Connections only after the client successfully exchanges its authorization code. Reauthorizing the same exact verified client identity leaves its current grant usable until that exchange succeeds, then replaces the previous permissions and credentials rather than creating another logical connection. Failed or abandoned reauthorization does not replace the current grant, and authorization codes expire automatically. Authorization metadata and active connection metadata are retained so the connection can operate and be audited.

Control and destination: Review or revoke MCP clients under Connections -> MCP. A client can use the standard server-to-server token-revocation endpoint, but it may not notify Quantified Self when removed or uninstalled. Disconnect in Connections remains the authoritative control and immediately invalidates the current grant and any older duplicate records for that exact verified client without affecting other MCP clients. Account deletion removes MCP connection and authorization state. A client may retain data it already received according to its own privacy and retention practices, so authorize only clients you trust.

Google Cloud: Quantified Self stores application data, connected-service metadata, and processing state on Google Cloud in the EU region.

Stripe: Stripe processes subscription and billing data needed to charge, renew, and manage your plan.

Google Analytics: If you consent to analytics cookies, Google Analytics receives anonymized usage analytics used to improve the service. Analytics is optional and can be withdrawn in Settings.

Mapbox: When you use location-based AI Insights queries or authorize an MCP client that searches by place name, Mapbox is used to resolve the supplied place text and geographic scope. Direct-coordinate MCP searches do not call Mapbox.

Google GenAI / Gemini: AI Insights currently uses Google's Gemini models through Google GenAI. Quantified Self sends only the minimum derived statistics needed to answer the prompt you explicitly submit. Raw activities, raw routes, uploaded FIT/GPX/TCX/JSON/SML files, and saved route source files are not sent to the AI provider.

No hidden provider forwarding: Connected Garmin, Suunto, COROS, and Wahoo data is only sent to destination providers when you explicitly use the related import, upload, delivery, or sync feature. Wahoo delivery is limited to the explicit FIT activity, GPX/FIT course/route, opt-in Suunto saved-route, and Garmin/COROS/Suunto-to-Wahoo activity workflows described above.