Privacy Policy

What data we collect

When you use freddy, we collect:

• Email address — used for authentication via 6-digit sign-in code and account identification.
• Provider OAuth tokens or API keys — used to sync data from the health, fitness, and environmental data sources you choose to connect (for example wearables, rings, smart scales, continuous glucose monitors, training platforms, and home environmental sensors; the current list is shown in the app). These credentials grant read-only access to your account with each source.
• Health and environmental metrics — sleep, heart rate, HRV, activity, workouts, recovery, body measurements, glucose data, nutrition and dietary intake, mindfulness and mental-wellbeing sessions, medication and treatment data (such as insulin delivery and inhaler use), home environmental readings (such as air quality, radon, CO₂, temperature, and humidity), and other health-related metrics synced from the sources you connect. Stored as structured rows in our database.
• Precise location (from activity data) — when you connect a source that records activity routes (for example a GPS-enabled wearable or training platform), the recorded activity data we sync can include precise location coordinates, such as the start point and route of a run or ride. This is part of your health data: it is stored encrypted at rest and is available to you and to the AI assistant you connect, the same as any other metric you sync. We do not use it to determine, track, profile, or infer your location or your presence at any place, and we do not derive geofences from it.
• MCP request audit log — when you make a request to your personal MCP URL, we record the request method, path, tool name, a redacted summary of the tool arguments (encrypted at rest), HTTP status, duration, your IP address, and your user-agent string. This audit log is shown to you on your dashboard so you can detect unauthorized use of your MCP token. We retain audit-log entries for 90 days, then permanently delete them. Lawful basis: legitimate interest under Article 6(1)(f) UK GDPR / EU GDPR (security audit, and, in the aggregate form described under "Service performance measurement" below, measuring the performance of the Service). You can download a CSV copy at any time from your dashboard.
• Support chat messages and attachments — when you write to us in the in-app support chat, we store your messages and any screenshots or other files you attach. Message bodies and attachments are encrypted at rest. We use them to answer you, and, as described under "Support" below, an AI model helps us draft the reply.
• Purchase and subscription records — if you buy a paid plan, we store which plan you are on, where you bought it (our website, the App Store, or Google Play), and the transaction and subscription identifiers we are given. For a subscription we also store when the current period ends and whether it is set to renew. We never receive or store your card number.
• Server-side page-view analytics — when you visit a page on freddy.coach (marketing site, dashboard, articles, guides, help, changelog, or any other non-MCP surface), our server records the request path, HTTP status, response size, response time, referrer, IP address, and user-agent string. This is used in aggregate to understand which pages people visit and which referrers send traffic. We do not use cookies, beacons, or any client-side tracker for this. IP addresses are retained for 30 days and then truncated. Lawful basis: Article 6(1)(f) UK GDPR / EU GDPR (legitimate interest in operating the service and measuring its reach).

We do not collect data beyond what is needed to provide the Service. We do not track you across websites or use cookies for advertising.

How we use your data

Your data is used to power your personal MCP endpoint and, when you contact us, to support you. When an AI client you have connected queries your freddy endpoint, we read your stored health metrics and return them in the response.

Push notifications. If you allow notifications in the freddy app, we store a token for each device you sign in on, with its app and OS version and time zone, so we can reach it at a sensible local hour. Notifications are only about your account — for example, that a source has stopped sending data. The wording comes from a fixed set we write, and never includes your health data. We do not send marketing notifications, and you can turn them off at any time.

Payments. If you upgrade to a paid plan, your payment is handled by the provider you buy through. For purchases made on our website that is Stripe; for purchases made through the App Store or Google Play it is Apple or Google, and we use RevenueCat to tell us which of those subscriptions are active so that PRO unlocks on the right account. BELIEVER is a one-time purchase on our website, handled by Stripe, and is not a subscription. We never see your card number. We use these records to give you the plan you paid for, to meet our tax and accounting obligations, and to decide which service emails you get, so that we are not sending upgrade prompts to someone who has already upgraded.

Service performance measurement

We measure the performance and reliability of the Service itself so that we can detect, diagnose, and remedy degradation, errors, and outages in it: request duration, the volume of work a request required, the outcome of the request, and the delay between data arriving from a connected source and becoming available to you. Some of this measurement is in place today and some of it is still being built; the limits set out in this section apply to all of it.

Where a measurement derives from a request made through your MCP endpoint, we record the shape of the request, not its content: values such as the tool invoked, the requested time span as a bucketed range (for example "up to 30 days" or "over one year"), the granularity asked for, the number of rows read, and the outcome. These measurements do not include which metrics you asked about, the specific dates you asked for, or any other value that describes you rather than the work performed. Those details are recorded only in the MCP request audit log described above, encrypted and deleted after 90 days.

These figures are held as aggregate counts only, with no link to any individual user, and contain no health values. Because they carry no per-user link, they are retained beyond the 90-day retention of the audit-log entries from which they derive. Lawful basis: Article 6(1)(f) UK GDPR / EU GDPR (legitimate interest in operating, measuring, and maintaining the Service).

Support

When you write to us in the in-app support chat, we use Anthropic's Claude models to help us answer. The model sees your support conversation, any screenshots you attach, and basic account details: your plan, the date you signed up, and how many sources you have connected. If you have switched on "Help us debug this", it can also see technical information about your connected sources: which sources they are, when each one last synced, which syncs failed and the error type, and, for each metric a source has sent, how many records it holds and the dates they cover. We don't send it your stored health metrics. Anthropic processes this content under a data processing agreement with us and does not train its models on it. Neither do we.

"Help us debug this" is off unless you turn it on. It switches off when the conversation is closed, and you can turn it off any time.

Children and minors

freddy is not intended for, and not directed at, individuals under 18 years of age. We do not knowingly collect data from anyone under 18. If you become aware that a person under 18 has created a freddy account, please contact us at [email protected] and we will delete the account and all associated data.

Connected data sources

freddy reads data from the third-party accounts and devices you choose to connect — for example wearables, fitness trackers, rings, smart scales, continuous glucose monitors, training platforms, and home environmental sensors. We access it on your behalf, at your direction, with read-only credentials you authorize, only for the sources you connect. Each source is operated by its own company under its own privacy policy and terms, and is the origin of your data. The specific services available to connect are shown in the app; we add new ones over time without changing this policy.

When you connect a source, you authorize freddy to access your data from it. You can review your connected sources and disconnect any of them at any time from your dashboard.

Garmin data

How we collect it. We access your Garmin data only after you connect your Garmin Connect account and authorize freddy through Garmin's OAuth flow. We use the Garmin Health, Activity, and Women's Health APIs to read the health and activity data in your Garmin account, including the activity files your device records in full rather than summaries of them. What we receive depends on which Garmin device you use and what it records. Access is read-only. We never write data back to Garmin Connect.

How we use it. We store your Garmin data so you can query it through your own connected AI assistant. freddy does not perform AI or machine-learning processing on your stored Garmin data and does not use it to train any model.

How we process and store it. Your Garmin data is encrypted at rest (AES-256-GCM) and hosted by Railway in the United States, alongside your other connected health data. It is held in our PostgreSQL database, except that larger raw payloads such as recorded activity routes are held in encrypted object storage on the same United States infrastructure. In transit, requests are decrypted and inspected at the edge location nearest you, which may be outside the United States, by our hosting provider's edge network and by Cloudflare; neither retains the contents.

Sharing and third parties. We do not sell, rent, or broker your Garmin data, and we do not share it with advertisers or data brokers. Garmin data is transmitted to a third party only when you direct it: when you query freddy through your personal MCP URL, your chosen AI assistant (for example Claude, ChatGPT, or another MCP-compatible client) reads your stored data to answer you. Those assistants act on your behalf, at your direction, and are governed by their own privacy policies. Our infrastructure sub-processor Railway (United States) hosts the database; our edge-network sub-processor Cloudflare decrypts and inspects requests and responses in transit, retaining the contents of neither; our error-monitoring sub-processor Sentry receives technical error metadata only and never receives your Garmin health data; and, if you ask us for help in the in-app support chat and switch on "Help us debug this", our support sub-processor Anthropic (United States) receives your Garmin sync status, error classifications, and per-metric record counts and date ranges, never your Garmin health values. We perform no third-party AI or analytics processing on your stored Garmin data ourselves.

Your control. You can disconnect Garmin at any time from your dashboard, which deletes your stored Garmin data. If you disconnect through Garmin Connect, Garmin notifies us and we delete your Garmin data automatically.

Attribution. Garmin device-sourced data shown in freddy is attributed as "Garmin [device model]".

Data storage and security

Your data is stored in a PostgreSQL database hosted on Railway, on infrastructure located in the United States. The underlying storage volume is encrypted at rest. All connections to the database use TLS encryption. MCP endpoints are served over HTTPS only; that TLS connection is terminated at the edge networks in front of the Service, as described under "Data location and international transfers" below.

Your health metrics (sleep, workouts, recovery, raw payloads), as well as the OAuth tokens and API keys for your connected providers, are additionally encrypted at the application layer using AES-256-GCM before being written to the database. The encryption key is held in our deployment environment, separately from the database credentials, so a leaked database backup or storage-layer compromise yields ciphertext rather than usable values. Provider credentials are never exposed through the MCP endpoint.

Some of these raw payloads — chiefly large activity records, which can exceed what we store inline in the database — are held in a separate object-storage system rather than in the database itself. That storage is on the same infrastructure located in the United States, and the payloads are encrypted with the same AES-256-GCM application-layer encryption before being written to it, so they are stored as ciphertext just like the database rows.

Our error-monitoring sub-processor (Sentry) is configured to drop request bodies, breadcrumb payload data, and third-party API response bodies attached as error context before transmission. Sentry receives stack traces, request URLs (with MCP tokens redacted), HTTP status codes, and operational metadata — not the contents of your health metrics. This is enforced by code, not by policy alone (see the beforeSend hook in our Sentry initialization).

Application-layer encryption protects against scenarios where data leaves the database boundary (such as backup leaks). It does not by itself defend a compromise of the running application, which would have access to both the data and the key in memory. This is the standard tradeoff for any hosted service that performs server-side processing. We comply with the New York SHIELD Act's data-security program requirements and analogous state requirements through these technical and administrative measures.

Security incidents and breach notification

freddy is a "vendor of personal health records" under the FTC Health Breach Notification Rule (16 CFR Part 318). We are not a HIPAA-covered entity.

In the event of a breach of security involving unsecured personal-health-record-identifiable health information — including unauthorized acquisition or disclosure, not only external intrusion — we will:

• Notify each affected individual without unreasonable delay, and in no event later than 60 calendar days after discovery of the breach, with the content required by 16 CFR § 318.6 (a description of the incident, the categories of information involved, the steps individuals can take to protect themselves, the steps we are taking to investigate and mitigate, and contact information).
• Notify the Federal Trade Commission as soon as possible and in no case later than 10 business days following the date of discovery if the breach affects 500 or more individuals; otherwise, as part of our annual notification submission.
• Notify prominent media outlets serving the relevant state if the breach affects 500 or more residents of that state.

Notice channel. Because you create your freddy account using only an email address, and because all communications between us and you (sign-in codes, account notifications, billing receipts) occur by email, we treat email as your "primary method of communication" within the meaning of 16 CFR § 318.5(a)(1), and individual breach notices will be delivered by email to the address associated with your account. If you would prefer to receive breach notices by first-class mail, please email [email protected] with a postal address and we will use that channel for future notices.

For consumers in jurisdictions with additional or more protective breach-notification requirements (for example, UK GDPR Article 33–34, EU GDPR Article 33–34, California Civil Code § 1798.82, or analogous state laws), we will additionally comply with those requirements.

Data location and international transfers

freddy is operated by reThrive Labs LLC, a company incorporated in the State of Wyoming, United States. All your data — your account, your provider credentials, and your synced health metrics — is stored on infrastructure located in the United States. Requests in transit are decrypted and inspected at the edge location nearest you, which may be outside the United States, by our hosting provider's edge network and by Cloudflare; neither retains the contents.

If you are accessing the Service from the United Kingdom, the European Economic Area, or another jurisdiction with data protection laws different from those in the United States, please be aware that:

• The United States has not been determined by the UK or the EU to provide a level of data protection equivalent to UK GDPR or EU GDPR.
• You may have fewer or different enforceable rights against us under US law than you would have against a UK- or EU-based service.
• Because requests are decrypted in transit at the edge location nearest you, a request you make while travelling may be processed briefly in a third country whose data protection laws differ again. Nothing is stored there.

By creating an account and accepting these Terms and this Privacy Policy at signup, you give your explicit informed consent to the storage and processing of your data — including health data, which UK and EU law classifies as special-category personal data — in the United States, and to the transient decryption and inspection of your requests in transit at the edge location nearest you, wherever in the world that location is. This is the lawful basis on which we transfer your data internationally, under Article 49(1)(a) of UK GDPR and EU GDPR.

You can withdraw this consent at any time by deleting your account. When you do, your account record, all stored health metrics, all provider connections, and your MCP token are permanently deleted from our systems. We are working toward UK-US Data Bridge self-certification under the EU-US Data Privacy Framework, which will provide an additional Article 46 transfer mechanism. When that is in place, this Policy will be updated to reflect it.

Lawful bases for processing

For users in the UK and the EEA, we rely on the following lawful bases under Article 6 and Article 9 UK GDPR / EU GDPR:

• Article 6(1)(b) — performance of a contract: for processing necessary to deliver the Service you have signed up for (account management, syncing data from providers you have connected, serving your MCP endpoint).
• Article 9(2)(a) — explicit consent: for processing your health data, which is special-category personal data. Your acceptance of these Terms and this Privacy Policy at signup constitutes that explicit consent. You can withdraw it by disconnecting individual providers (which deletes that provider's data) or by deleting your account (which deletes everything).
• Article 49(1)(a) — explicit consent for international transfers: as described in the section above.

California residents (CCPA / CPRA)

If you are a California resident, you have the following rights under the California Consumer Privacy Act, as amended by the California Privacy Rights Act:

• Right to know what categories of personal information we collect, the purposes, the sources, and the categories of recipients. These are set out in the sections above.
• Right to access and obtain a copy of the personal information we hold about you.
• Right to correct inaccurate personal information.
• Right to delete personal information we have collected.
• Right to portability — receive your personal information in a portable, readily usable format (CSV export from your dashboard).
• Right to non-discrimination for exercising any of these rights.

We do not sell personal information and we do not share personal information for cross-context behavioral advertising as those terms are defined under the CCPA. We have not done so in the preceding 12 months and we have no plans to do so.

Sensitive personal information. Health data is "sensitive personal information" under the CCPA. We use sensitive personal information to provide the service you have requested, to operate the freddy MCP endpoint at your direction, to support you when you contact us, and for the purposes of ensuring the security and integrity of the service (CCPA Regulations § 7027(m)(2)). We do not use sensitive personal information for any purpose that would require us to offer a "Limit the Use of My Sensitive Personal Information" mechanism under the CCPA.

To exercise any of these rights, email [email protected]. We will verify your request by confirming control of the email address associated with your account and respond within 45 days of receipt (extendable by an additional 45 days where reasonably necessary, with notice to you within the original window). You may also use an authorized agent; we require written authorization and verification of the agent's identity before processing the request.

Other US state residents

If you are a resident of a US state with a comprehensive consumer privacy law (including but not limited to Texas, Colorado, Virginia, Connecticut, Utah, Oregon, Montana, Iowa, Tennessee, Indiana, Delaware, New Hampshire, New Jersey, Maryland, or Minnesota), you have rights that may include the right to access, correct, delete, port, and (where applicable) opt out of the sale, sharing, profiling, or processing of your sensitive personal data including health data. We do not sell or share your data, and we do not engage in profiling that produces legal or similarly significant effects. To exercise any state-law right, email [email protected] and we will respond within the timeframe required by your state's law (typically 45 days). You have the right to appeal any denial; if we deny your appeal, you may file a complaint with the consumer-protection authority in your state.

Washington, Nevada, and Connecticut consumers have additional rights specific to "consumer health data" set out in our separate Consumer Health Data Privacy Policy, which is incorporated into this Privacy Policy by reference.

Sub-processors

We use the following sub-processors to deliver the Service. Each is bound by their standard data processing terms:

• Railway — application hosting and database infrastructure (United States).
• Resend — transactional email delivery (United States).
• Stripe — payment processing for plans bought on our website, both PRO subscriptions and one-time BELIEVER purchases (United States, with Stripe's UK and EU entities for European users).
• Sentry — application error monitoring (United States). Sentry receives error metadata; it does not receive your health data.
• Anthropic — Claude models used to help answer support requests (United States). Sees your support conversation, any screenshots you attach, and basic account details: your plan, the date you signed up, and how many sources you have connected. While "Help us debug this" is on, it also sees technical information about your connected sources. We don't send it your stored health metrics.
• Apple — push notification delivery to iPhone and iPad, and payment handling for PRO subscriptions bought in the freddy app on iPhone or iPad (United States). For notifications it sees a device token and the notification text. For purchases it takes the payment itself and tells us that a subscription is active, its identifiers, and when it renews. Not your health data, and we never receive your card number.
• Google — push notification delivery to Android devices, and payment handling for PRO subscriptions bought in the freddy app on Android (United States). For notifications it sees a device token and the notification text. For purchases it takes the payment itself and tells us that a subscription is active, its identifiers, and when it renews. Not your health data, and we never receive your card number.
• RevenueCat — subscription management for purchases made through the App Store or Google Play (RevenueCat, Inc., United States). Receives your freddy account identifier, the purchase records for your subscription, and technical connection data such as your IP address, and tells us which subscriptions are active so PRO unlocks on the right account. It does not receive your health data, your payment details, or any advertising identifier.
• Cloudflare — edge network providing DNS, TLS termination, and protection against denial-of-service and abusive traffic (globally distributed network; company incorporated in the United States). Decrypts and inspects requests and responses in transit, which includes your health data. It does not store your health data: responses carrying health data are not cached at the edge. Static files such as images, fonts, and scripts are cached there, as on any content delivery network. Where a request triggers one of its security protections, Cloudflare records that request's metadata — its IP address, user-agent string, and URL path — in its own security log for a short period. Your personal MCP URL carries your MCP token in that path; you can rotate it at any time from your dashboard.

Data retention and deletion

We retain personal data only as long as needed for the purposes for which we collected it. Retention by category:

• Account record (user row, email, account identifier) — retained while your account is active; deleted within 30 days of account deletion.
• Health metrics (from connected providers) — retained while the relevant provider is connected. Disconnecting a provider deletes its data immediately. Deleting your account deletes all health metrics within 30 days.
• Provider credentials (OAuth tokens, API keys) — retained while the provider is connected; deleted immediately on disconnect.
• MCP request audit log — retained for 90 days, then deleted by a daily cleanup job. Account deletion removes audit-log entries immediately.
• Server-side page-view analytics — IP addresses retained for 30 days, then truncated. Path/referrer/UA retained indefinitely in aggregated form only (no per-user link).
• Service performance measurements — retained indefinitely in aggregated form only (no per-user link), which is longer than the audit-log entries from which some of them derive.
• Billing records (subscription and transaction identifiers from Stripe, the App Store, or Google Play, and plan history) — retained for 7 years to satisfy US tax and accounting requirements, even after account deletion.
• Transactional email metadata (delivery receipts, bounces, opens) — retained at our email provider (Resend) per their default retention; we do not maintain a long-term copy.
• UserConsent rows (acceptance timestamps + IP/UA) — retained for the lifetime of the account as the legal basis evidence; deleted on account deletion.
• Support chat content (your messages, any screenshots or other files you attach, and the reply drafts our support tools build from them) — retained while your account is active so we and you keep the history of what you asked; deleted on account deletion. A draft is a copy of the information it was built from, so any draft built while your "Help us debug this" grant was live is cleared when that grant ends.
• Push notification tokens (device token, install identifier, app and OS version, time zone) — kept while the device stays signed in; deleted when you sign out on it, revoke its session, or delete your account. If Apple or Google reports a token as no longer valid we stop sending to it.

You can disconnect providers from your dashboard or delete your account at any time.

If you bought a subscription through the App Store or Google Play, deleting your freddy account does not cancel it. We cannot cancel a store subscription from your freddy account. Cancel it in the App Store or Google Play first, then delete your account.

Your rights

You have the following rights with respect to your personal data:

• Access — request a copy of the personal data we hold about you, including your synced health metrics, via your MCP endpoint, the dashboard data viewer, the CSV export tool, or by emailing us.
• Rectification — request correction of inaccurate personal data.
• Erasure — delete data by disconnecting individual providers (immediately deletes that provider's metrics) or by deleting your account (deletes everything within 30 days).
• Restriction — request that we restrict processing of your data in specific circumstances.
• Portability — receive your personal data in a structured, commonly used, machine-readable format (CSV export from your dashboard).
• Objection — object to processing that relies on legitimate interest as a lawful basis.
• Withdraw consent — by disconnecting a provider (stops processing of and deletes data from that provider) or by deleting your account.
• Appeal — appeal any denial of a rights request by emailing [email protected] with the word "appeal" in the subject; we respond in writing with reasons within 45 days.
• Complain to a supervisory authority — UK residents may complain to the Information Commissioner's Office (ico.org.uk); EU/EEA residents may complain to their national data-protection authority; Washington residents may file with the WA Attorney General (atg.wa.gov/file-complaint); California residents may file with the California Privacy Protection Agency (cppa.ca.gov).

To exercise any of these rights, email [email protected]. We respond within 45 days of receipt of a verifiable request. We may extend this by up to a further 45 days where the request is complex or numerous, and will notify you of the extension within the original 45-day window. We do not charge for these requests except where they are manifestly unfounded or excessive.