The API Trap: How Wearable Companies Make Your Health Data Disappear When You Cancel
TL;DR
Most wearable companies let you export your health data the same way a bank lets you withdraw your money: through a narrow funnel, in a format you cannot use, and only while you are still a customer. The API is not there to help you. It is there to let partners build features that keep you subscribed. Pulsyn stores everything locally in SQLite with an open schema. You own the file. You do not need our permission to read it.
What happens when you cancel
When you cancel Oura, you do not lose the ring. You lose the data. The app goes into a limited mode that shows you yesterday's sleep and nothing else. Historical trends, readiness baselines, the two years of HRV data you paid for: gone from view. The ring still collects it. The sensors still work. The data still exists on their servers. You just cannot see it.
Whoop is worse. Cancel the monthly subscription and the device becomes a brick. Not a limited brick. A full brick. The screen does nothing. The strap might as well be a fitness band from Target. Fitbit Premium is gentler. You keep basic step counts without the subscription. But the detailed sleep stage breakdowns, the historical trends, the wellness report you generated: those vanish.
This is not a technical limitation. It is a design choice. The companies could let you keep read-only access to historical data. They could let you export everything before you cancel. They choose not to because every barrier between you and your data is another month of subscription revenue.
We have an API is not the same as your data is portable
Every wearable company advertises an API. Oura has a developer portal. Fitbit has a Web API. Apple HealthKit exists. Garmin has Connect IQ. The problem is who the API serves.
Oura's API requires OAuth approval. It is rate-limited to 5000 requests per day for personal access and 100 requests per minute. It does not export raw sensor data. It exports scored summaries. You cannot get the original PPG waveforms, the original accelerometer samples, or the raw temperature readings. You get sleep score: 82 and readiness: 71. Those numbers are proprietary algorithms applied to your data, and if you leave, you have no way to recalculate them.
The API documentation lists endpoints like /v2/usercollection/daily_sleep and /v2/usercollection/daily_readiness. The responses are JSON objects with fields like score, contributors, and timestamp. Contributors breaks down into things like efficiency, latency, and rem_sleep. But the raw data underneath, the 30-second epoch data that actually produced those scores, is not available through the public API. If you want to run your own sleep analysis, you cannot. You can only download their interpretation.
Fitbit's API, after the Google acquisition, has become progressively stricter. Third-party apps that used to sync freely now face quota cuts and review processes. The API that was pitched as open is now a partner program with a waitlist. Google announced in 2023 that Fitbit Web API access would require OAuth 2.0 with PKCE, restricted scopes, and a verified developer account. Small apps that previously pulled step counts for local dashboards have been shut out. The data that used to flow to your own tools now stays in Google's platform.
Apple HealthKit is the closest to genuine portability, but it is a one-way street. Data flows in from apps through HKHealthStore, but getting it out in a structured, queryable format requires writing an app of your own. The export file Apple generates is a ZIP of XML. Each data point is wrapped in a Record element with type, sourceName, and value attributes. Good luck querying that without writing a parser. There is no SQL interface. There is no JSON export. There is no way to get a clean time-series CSV of your heart rate without third-party software that reverse-engineers the XML.
Garmin is the outlier in the other direction. Garmin Connect lets you export TCX and FIT files with raw GPS and sensor data. The files are binary but well-documented. Third-party tools like GoldenCheetah can parse them. Garmin earns its money on hardware margins, not subscriptions, so it has less incentive to trap your data. But Garmin is a wristwatch, not a ring, and the form factor difference matters for sleep tracking.
The API is not a bridge. It is a turnstile. It lets the right partners in and keeps the data from leaving.
Why lock-in is the business model
Wearable economics are simple. The hardware margin is thin. We covered this in the hardware margins post. Oura sells a ring for $349 that costs roughly $30 to manufacture. Whoop ships you a strap for free because they know the real product is the subscription. The real money is not in the device. It is in the recurring revenue.
Oura's yearly subscription is not paying for cloud storage. Cloud storage for 2 MB of daily JSON costs pennies at AWS S3 prices. Even with replication, backups, and CDN, the infrastructure cost per user is under a dollar per year. The subscription pays for the lock-in.
When your data is trapped in a proprietary format on a server you do not control, the cost of leaving is not just the new device. It is the loss of your history. Your baselines. Your patterns. The knowledge that your HRV drops before you get sick, or that your deep sleep correlates with room temperature. That friction is intentional. It is called high switching costs, and it is taught in every business school as a way to reduce churn.
Whoop took this to its logical conclusion: no device purchase option at all. You rent the hardware and the data together. Cancel, and you lose both. It is the most honest version of the model, because it does not pretend you ever owned anything. You did not buy a fitness tracker. You subscribed to a biometric surveillance service that happens to come with a wristband.
I am not sure if the subscription model is inherently evil. Some services genuinely need ongoing infrastructure. A cloud backup service that stores your photos on redundant drives justifies a monthly fee. But in wearables, the ongoing cost is a fiction. The compute is on your wrist or finger. The storage is a rounding error. The subscription is rent on data you generated yourself with sensors you already paid for.
GDPR and the right to portability
European readers might be shouting GDPR at this point. Article 20 grants a right to data portability. Companies must provide your data in a structured, commonly used, machine-readable format. The regulation sounds strong. The reality is weaker.
In practice, portability means you get a CSV. A 400-row CSV with columns like date, sleep_score, steps, heart_rate. No metadata. No sensor calibration history. No algorithm version numbers. No explanation of how the sleep score was derived. A CSV is machine-readable in the same way a photograph of a spreadsheet is machine-readable. Technically true. Practically useless for anyone who wants to continue tracking without the original app.
The GDPR text says the format should be structured, commonly used, and machine-readable. It does not say it has to be useful. It does not say it has to include derived data. It does not say companies must document their schemas. A company can comply by handing you a JSON dump of internal database rows with cryptic field names, and they have.
I requested my Oura data under GDPR in 2024. The response took 28 days, which is within the legal limit but longer than most free trials last. The file was 11 MB of mostly JSON with internal field names like sleep_efficiency_2_0, readiness_score_v2, and undocumented enums where 1 meant restless and 2 meant awake but the mapping was not included. I spent an afternoon writing a parser. Most users will not. Most users will look at the export, realize it is incomprehensible, and stay subscribed. Which is the point.
The deeper problem is that GDPR portability only applies to data the user provided. It does not clearly cover derived data, algorithmic inferences, or scored summaries. Your raw accelerometer readings might qualify as data you provided. Your sleep score, which is an algorithmic inference, might not. Companies exploit this ambiguity. They give you the raw inputs and keep the outputs, knowing that the outputs are what you actually care about.
How Pulsyn does the opposite
Pulsyn stores your data on your phone, not our servers. The database is a SQLCipher-encrypted SQLite file with an open schema. The tables are named things like sleep_sessions, hrv_readings, steps_daily, and skin_temperature. The columns are standard types: REAL for sensor values, INTEGER for flags, TIMESTAMP for dates. There is no proprietary scoring layer between you and the raw data.
If you want to export everything, you tap a button and get a plain SQLite file. You can open it in DB Browser for SQLite, query it with SQL, import it into Python with pandas, or sync it to your own server with rsync. We do not wrap it in XML. We do not rate-limit the export. We do not ask why you want it. The file is yours. It leaves your phone the same way any other file does: through the share sheet, AirDrop, USB, or whatever method you prefer.
The schema is documented on our developer page. We publish the CREATE TABLE statements. We explain what each column means, what units it uses, and how the timestamps are formatted. If you want to build a dashboard that plots your HRV against the weather, you can. You do not need our approval. You do not need an API key. You need the file, which is already on your phone.
The encryption key is derived from a PIN only you know. We covered the encryption details in the SQLCipher post, but the relevant part here is simple: even if you cancel, the file is still on your phone. We cannot delete it. We cannot lock you out of it. We literally do not have the key. The PIN never leaves your device. It is not backed up to iCloud. It is not stored in our database. If you forget it, the data is unrecoverable, which is exactly how it should be.
We are also designing an open API that runs locally on your device. Third-party apps will be able to query your Pulsyn data through a local HTTP endpoint, not a cloud server. That means a meditation app could pull your HRV in real time without your data ever leaving your phone. A training platform could read your recovery status without uploading it to their cloud. We are not gatekeeping integrations with a partner program or OAuth approval queue. If an app can make a local network request to localhost, it can read your data. With your permission, of course. The permission model is simple: you tap approve when the app requests access, same as iOS location permissions.
This changes the economics of integration. For a developer, building against Oura's API means registering as a partner, waiting for approval, handling OAuth, respecting rate limits, and potentially losing access if Oura changes its terms. Building against Pulsyn's local API means making HTTP requests to a documented endpoint on the user's own device. No account required. No server required. No trust in us required.
What users should actually demand
I am not optimistic that regulation will fix this. GDPR passed in 2016. The situation has gotten worse, not better. The problem is that portability is interpreted as we gave them a file, not they can actually use the file. Until the law defines usable portability, companies will comply with the letter and violate the spirit.
What would actually change the market is user expectation. If buyers started asking what happens to my data if I cancel before purchasing, the sales pages would change. If reviewers scored wearables on data portability the same way they score battery life, companies would compete on it. A review that says this ring tracks sleep well but holds your data hostage would do more damage than a thousand GDPR complaints.
Here are the questions I think every buyer should ask:
Can I export my data without contacting customer support? Can I read the export with standard tools like Excel, SQLite Browser, or a text editor? Does the export include raw sensor data or only scored summaries? If I cancel my subscription, can I still access historical data? Is the data stored on my device or only in the cloud?
If any answer is no, the device is not yours. You are leasing it, and the lease terms include your biometric history.
There is a counterargument I have heard from product managers at these companies. They say that most users do not want their data. They want an app that works. They want insights, not spreadsheets. I think that is half true. Most users do not want their data today, while the app is working and the subscription is active. But the moment the app stops working, or the price goes up, or the company gets acquired, the demand for portability spikes. That is when users discover the trap. By then it is too late.
Until then, the only real protection is architecture. Data that lives on your phone, encrypted with your key, in an open format, cannot be held hostage. Not because of a privacy policy. Not because of a regulation. Because of physics. We do not have it. We cannot take it away. That is the only guarantee that means anything.
About the author
James Hoffmann is the founder of Pulsyn. He has been building local-first health software for two years and believes the best privacy guarantee is a system design that makes data collection technically impossible.
References
- Oura Developer Documentation : API reference and data export limitations (ouraring.com/developer)
- Fitbit Web API : developer guidelines and rate limits (fitbit.com)
- Apple HealthKit : data export documentation (developer.apple.com)
- European Commission : GDPR Article 20: Right to data portability (gdpr.eu)
- Pulsyn blog : How Pulsyn Encrypts Your Health Data: SQLCipher, 600,000 PBKDF2 Iterations, and Why We Do Not Know Your PIN (getpulsyn.com/blog/how-pulsyn-encrypts-your-health-data-sqlcipher-600000-pbkdf2-iterations-and-why-we-do-not-know-your-pin)
