Privacy Policy

Last updated 28 August 2026. Covers the Fitness Autopilot Chrome extension, the Fitness Autopilot iOS app, and fitnessautopilot.app.

1. Who we are

Fitness Autopilot is the controller of the personal data described here. Reach us at support@fitnessautopilot.app for any question, request, or complaint about this policy.

2. Notice at collection

This section is the summary California's CCPA/CPRA requires you be given at or before the point of collection. Detail follows in §3, §4 and §5.

We have never sold personal information for money. We do "share" a limited set of it for cross-context advertising as described in §7 — you can opt out at any time, and Global Privacy Control is honored automatically.

3. Google user data — what we get, and what we cannot get

This section is about the Chrome extension, which is where our Google connection does the most work. The iOS app's optional Google and Outlook connections are a different path with a different answer, and they are in §4.

Connecting your calendar grants one sensitive scope: https://www.googleapis.com/auth/calendar.events.owned. Google describes it as "See, create, change, and delete events on Google calendars you own." That is the only scope that can write an event, and Google offers no narrower one. Here is precisely what we do with it.

What we receive

• Busy time ranges only. Our request carries a field mask — items(id,status,transparency,start,end,extendedProperties/private) — and Google returns only the fields we ask for. Titles, guest lists, locations, descriptions, attachments and conference links are never sent to us, so we could not disclose or leak them even by mistake.
• The blocks we created. Each is tagged extendedProperties.private.faBlock. Every change or deletion we make matches on that tag, so an event we did not create is out of our reach by construction, not by promise.

What we store

Less than you would guess. Your busy time ranges solve the day and are then gone — what gets written down is the plan itself: the window we chose, when to leave, how long the travel is. Alongside it we keep the id of the block we created, and a one-way fingerprint of your busy set, which is how we notice your day has changed without keeping the day. There is no field anywhere in our system for what a meeting was, who was in it, or where it was.

What we never do

• Never read, store, or infer anything from meeting titles.
• Never touch a calendar other than the one you connect.
• Never use calendar data for advertising, targeting, or measurement — under any setting, and regardless of any consent you may have given for the site analytics in §7.
• Never sell it, and never use it to train a generalized AI or ML model.
• Never let a human read it, except with your explicit permission to fix a problem you report, or where required by law.

4. The iOS app

Everything above describes the Chrome extension and our web pages. The iOS app is a fuller product — training, nutrition, health — so here, in the same spirit, is exactly what it touches.

Your account and training data

Your account starts before you do. On first launch the app creates an anonymous account — a random id, attached to nothing about you — so your setup and your first program have somewhere to live without our asking you for anything. Signing in later with Apple or an email address attaches an identity to that same account; that is what lets it survive a lost phone, and it is the point at which we hold an address for you. Your profile and your training data — workouts, nutrition logs, body metrics, and your training profile — are stored in our hosted database (Supabase, in the United States) so they sync across your devices. They are kept while your account exists and destroyed when you delete it (§9).

Your calendar: we get the times, never the titles

The iOS app reads your calendar through Apple's EventKit, on the device. Placing the workout is a server call — the scheduler runs on our servers, with the same solver mirrored on the phone as the offline fallback — so the busy start and end times of your day are sent to us. The titles are not. Every event is rewritten to an empty title at a single point on the device before the request is encoded, so a new screen cannot leak one by forgetting to strip it; neither copy of the solver has ever read title content, and there is no column on our side to keep one in.

The one carve-out, stated plainly. In Settings you can additionally connect a Google or Outlook account, so the autopilot can re-plan while your phone is off or shut. That connection is read on our servers, and — unlike the extension in §3 — that request carries no field mask, so the calendar API hands back the whole event: its subject, its description body, its location, and who was invited. The first thing our code does with all of that is throw it away. What survives the door is the start, the end, an all-day flag, and the subject cut to its first 60 characters. The cut is ours, applied after receipt — not a limit the API imposed, and we would rather say that than let you believe Google or Microsoft withheld the rest.

That truncated subject is then used, and we will not describe it as inert. It is one of the inputs to the one-way fingerprint we take of your day — the thing that lets us notice your calendar changed and re-plan without keeping the day — and that fingerprint is stored against your account for as long as the connection lasts. It is also handed back to your phone with the day's times. What it is never an input to is the scheduling itself: the solver ranks times and has never read a title, on either the server or the phone. And there is still no field anywhere in our system that holds a subject, a description, a location or a guest list. The fingerprint is a single hash taken over the whole day at once, not a stored value per event. This connection is optional, it is separate from the calendar on your phone, and the same screen disconnects it.

Apple Health

With your permission, the app reads from and writes to Apple Health. Apple's permission sheet asks for five read grants — heart rate variability, resting heart rate, sleep, exercise minutes, and workouts recorded by your watch or another app — and one write: the workouts you log with us. Being exact about those five, because asking for a grant is not the same as using it. Two of them are read by the app today: exercise minutes, which becomes the ACTIVE figure on your Today screen, and workouts, so the app can see a session you recorded on your watch or in another app. The other three — heart rate variability, resting heart rate, sleep — are on the sheet ahead of a recovery feature that is not finished. No code in the app reads them today, and nothing sends them anywhere. You choose exactly which data types to grant on Apple's own permission screen, and you can revoke any of them in Settings at any time. What the app does read stays on the phone: what reaches our servers is what you log — the workout you record in the app, never a raw Health reading. We never use Apple Health data for advertising, marketing, or data mining, never sell it, and never disclose it to a data broker or an advertising platform — Apple's HealthKit rules require this, and we comply with them in full. Anything the app writes to Apple Health lives in your own Health record: it stays on your phone even if you delete the app.

Bloodwork

You can upload lab-result PDFs. Honestly stated: they are stored on our servers (Supabase storage), as attachments to the marker values you enter yourself — we do not claim your bloodwork never leaves your phone, because today it does. What we do enforce, in code: raw bloodwork never reaches any AI model. A screen at the write boundary keeps lab values, diagnoses, medications and other clinical detail out of the AI layer entirely; only non-clinical, derived training facts (such as an intensity cap) pass through.

The AI coach

The coach and the program designer run on open AI models reached through OpenRouter. Every call we make is restricted to providers that deny data collection — your prompts may not be used to train their models. Your messages are screened for health information before any model sees them, behind the same boundary as bloodwork. We store your conversation history and the programs the AI writes for you as part of your account, so your coach remembers you. We never use your data to train an AI model of our own or anyone else's.

Purchases

Apple processes every purchase — we never see your card or your payment details. We receive a receipt and validate it with Apple's servers, which tells us only what you own. The 30-day trial takes no card, and nothing auto-charges when it ends. The purchase model itself is in the Terms.

Crash reports and usage

The app sends crash and performance reports to Sentry so we can fix what breaks; we do not use them to track you.

Setting the app up. As you move through the setup questions, the app records which step you reached, which answer you picked, how long the screen was up and how many times you changed your mind — and sends them to us.

Almost every one of those is a token off a fixed list: the step names are a list of 28, and each question's answers are its own short list. Two stored values are not on such a list, and it is worth naming them. If you sign in during setup we record which of three methods you used — Apple, an email address, or a session you already had — never the address itself. And if building your program fails we record the error code our own server returned (VALIDATION_FAILED and the like): that is the one vocabulary we cannot close, because a new endpoint mints new codes and dropping them would blind us exactly when builds start failing, so it is held instead to the shape every code we issue has — capital letters and underscores, nothing else. Everything else is a number or a true/false.

A value that is not on its list is dropped rather than stored, and three separate locks do that — but they are not the same lock three times, and the order matters. The filter on your phone, before anything is sent, is a shape check: it drops anything that is not a short identifier — no spaces, no punctuation beyond _ . : + -, nothing over 48 characters. That stops a sentence; on its own it would not stop a single typed word. The vocabulary check is at our endpoint, where each value must actually be a member of its list, and any property we do not recognise is kept only if it reads as a number or a true/false — never as a string. The database is the third lock and re-checks the vocabulary itself, refusing the write outright rather than storing it. So the promise holds — nothing you type can arrive here even if we made a mistake, which is why the one free-text question in the flow reports only that you answered it and never a word of what you wrote — but it is our server and our database that carry it, not your phone.

These events travel under a random id minted for your install, plus a second one for that run through the setup. Neither is your account, a device id, or an advertising id. An account id does exist from your very first launch — that is what the anonymous account above means — so "you have not signed in yet" is not the reason it stays off these events. The real reason is narrower and checkable: the piece of the app that sends them authenticates with a public key that identifies the app rather than you, and never attaches your session, so our endpoint has no account to resolve and leaves that column empty on every row it writes. It would stamp an account id if a real sign-in token ever arrived with a batch; from this build, none does. What carries no account id cannot be matched to an erasure request or traced back to you — and anything that ever did carry one is deleted with your account, like everything else here.

Using the app. A closed list of eight moments is recorded against your account, so we can tell whether the product actually keeps people training. Here are all eight: the app was opened, the morning push was tapped, the Live Activity was interacted with, you saw your first solved day, a calendar was connected, a recap was opened, a micro-question was answered, a plan was abandoned. There is no text in any of them: each is one of those eight names, the calendar date it happened on where you are, and at most the id of the plan or recap it refers to — plus, on the calendar one, which of the three providers it was. There is nowhere in that for a note, a meeting title or an address to sit. The same request also carries your phone's timezone, which we store on your profile and keep current — it is what stops your day being counted, or your workout placed, in the wrong one after you fly somewhere. The events are deleted with your account.

The iOS app carries no ads, no third-party ad trackers, and, as everywhere in this policy, we do not sell your data.

5. The website

Our website and our extension are deliberately separate. The extension itself collects nothing — no analytics, no pixels, no tracking of any kind is present in the extension package. Everything in this section happens on our web pages only.

• A first-party ID stored in your own browser, so a second visit is not counted as a second person. It is a random value; it contains nothing about you.
• How you arrived — the referring site, campaign tags (utm_*), and advertising click IDs (such as gclid and fbclid) if you came from an ad. We keep the first one we see, not the most recent.
• What you did on the page — sections reached, scroll depth, which button you clicked, whether a form errored.
• Your device, coarsely — window size, language, timezone, mobile or not. We do not fingerprint: no canvas, no font probing, no plugin enumeration, no device memory.
• Your IP address, to derive coarse location and to rate-limit abuse. The full address is encrypted at rest and automatically destroyed after 180 days by a scheduled job. A truncated version, which cannot identify a household, survives that deletion so our country-level counts keep working.
• An email address you type into a form, to send you the install link.

If you are in the EEA or the UK, we do not retain your full IP address without your consent, and we do not load product analytics at all.

6. Legal bases (EEA / UK)

7. Advertising, and your opt-out

When we run ads, we measure whether they worked. To do that we may send Meta and Google, acting as our processors, a limited set of information: an email address you typed into one of our own forms (hashed — converted into an irreversible string before it leaves us), advertising click IDs, and the fact that a conversion happened.

How to opt out. In the EEA and UK this is off unless you opt in. Elsewhere:

• Turn on Global Privacy Control in your browser — we detect it automatically, honor it as an opt-out, and show a confirmation in our footer when we do.
• Or email support@fitnessautopilot.app and we will apply it to your record.

Once a conversion has been delivered to an advertising platform we cannot recall it from them. Opting out stops anything further; it cannot undo what already went.

8. Who else touches your data

We do not sell your data to anyone, and we do not buy data about you.

9. Your rights

Wherever you live, you can ask us to show you what we hold, correct it, or delete it. Email support@fitnessautopilot.app and we will action it within 30 days. Erasure is a real deletion, not a flag: your rows are removed, and a one-way hash of your address is kept on a suppression list for the sole purpose of ensuring a later signup cannot silently re-add you.

In the iOS app, a full export and a real account deletion are built into your account: the export gives you a machine-readable copy of your data, and deletion queues a real deletion on our servers. That queue runs seven days later — deliberately, so one mis-tap is recoverable, and the way back is inside the app. Open Settings → Delete account again at any point in those seven days and the screen tells you the date your account is due to be deleted and how much of the window is left, with a button that stops it: the app kept the cancel code the server minted when you asked, and that button spends it. If your account has an email address on it we email you the same code as well, and the screen has a field to paste it into — which is how you stop a deletion from a phone you have since reset or replaced. If neither is available to you — the code is not on the device you are holding, and the account has no email address on it — the screen says exactly that rather than showing you a button that could only fail, and asks you to email support@fitnessautopilot.app before the date, which we will act on. Stopping the deletion removes nothing: your sessions, logs and files are all still there. When the window closes the deletion is complete: your profile and every row that hangs off it, the lab PDFs you uploaded, and the login itself. Both the export and the deletion stay available regardless of your payment state — during the trial, after it lapses, and after a refund. Your data is never hostage.

Depending on where you live you may also have the right to object to or restrict processing, to receive your data in a portable format, to withdraw consent at any time, and to complain to your data protection authority. We will never treat you differently for exercising any of these.

You can disconnect Google at any time from your Google Account permissions page. We stop writing immediately. Blocks already on your calendar stay until you delete them — they are ordinary calendar events and they are yours.

10. Children

This service is not directed to anyone under 16, and we do not knowingly collect their data. If you believe a child has given us information, email us and we will delete it.

11. Changes

If we change this policy materially we will update the date at the top and, where the change affects data you have already given us, tell you directly rather than relying on you re-reading this page.