The Edit · Founder Insights
Your Body Scan Data Is Yours: Why Open APIs Beat Gated Access
Device makers that gate customer data behind partner programmes and calls are archaic. Open, rate-limited APIs protect servers and respect the owner.
A body scan is the client's data, so the client should be able to get at it through an open, documented API with published rate limits, and a device maker should not need a partner programme, a call or a fee to allow that. I run Catalyst Performance, a healthspan training studio in Manulife Tower in Singapore's CBD, and I build our own reporting software. Over the last few weeks I tried to connect one body composition analyser to that software, and it turned into a lesson about how not to sell hardware in the AI era.
TL;DR
- The person scanned owns the result, so access to that result should be self-serve, documented and limited by rate limits, not by a sales process.
- Rate limits, quotas and API keys protect a vendor's servers. Gates such as partner programmes, named-CRM integrations and "book a call" do not protect anything.
- Strava and GitHub publish their limits in public. UK regulators went further and required the largest banks to open up.
- Catalyst needs scan data to flow into its own reporting, and we will choose equipment partly on whether it allows that.
Why the scan belongs to the client
Every Catalyst client starts with the 4-Pillar Healthspan Assessment, and body composition is one of the four pillars. Skeletal muscle mass and waist-to-height ratio are two of the numbers I look at first, and I covered them in this earlier post. One scan tells you little. Ten scans over three years tell you whether a person is building the muscle that protects them in their 60s and 70s.
That trend lives in a report, and the report lives in software. At Catalyst the software is ours: Client 360 for the coaches and the Catalyst Coach app for clients. The scan has to land there on its own, without a coach retyping figures into a form.
So I hold a simple position. The person who stood on the device owns the result. The studio is a custodian, and the device maker is a supplier. A supplier can charge for the device, and it can charge for the software that interprets the scan. It should not be able to stand between the owner and the numbers.
What I asked for, and what came back
I wanted written API terms for one body composition analyser. For over a month we asked for them. What we were offered was calls, a partner process, and an integration with a gym CRM that we do not use.
I want to be fair to the maker, seca, because its strengths are real. seca's medical analyser, the mBCA, was validated against whole-body MRI for skeletal muscle mass in peer-reviewed studies from the University of Kiel (Bosy-Westphal and colleagues, 2017; Jensen and colleagues, 2019). Few BIA devices have that kind of evidence, and it is the reason clinics trust the brand.
The access side is where I found the gap. seca's own pages say the devices connect to its cloud software, seca analytics 125, and that results can be read in a browser or in a patient app. A June 2025 seca announcement says the software has interfaces to other providers such as EGYM, Magicline, Milon or DSB-ONE. A PerfectGym marketplace page describes a seca TRU integration that sends results to PerfectGym in real time, and says it is not available in every country. On the seca integration pages I read, I found no API documentation, no published rate limits and no way to generate a key. The page points you to a contact form.
The validation is strong. The access is a closed door with a contact form on it. A named partner here and a named CRM there is how device makers have long handled data, and I think the method is out of date.
It is not only seca. Catalyst has used InBody since its first day of operations, and I have worked with their machines for over a decade. InBody's own documentation describes its API as a paid service that you apply for, on top of the cloud account. Until you pay, the owner of a machine bought outright gets the data through InBody's app and the printout, and nothing more. The client paid for the scan, the studio paid for the machine, and the data still needs a further subscription to leave.
Mindbody, which runs our bookings and sales, sits in between. It gave me documentation and an API key without a call, which is the right start. The cost is the part I object to. On my plan, the first 5,000 calls in a billing cycle are free, and past that every call is billed, not only the extra ones. The studio was making around 8,000 calls a month, so I built a meter into our operations panel and cut the calls. The bill is small. The principle is not: a studio pays a fee to read its own bookings. Mindbody's developer pages also publish no limits; they say a developer's daily call limits are set when the key is issued.
What a rate limit does that a gate does not
I run my own servers, so I do not argue that a vendor must hand out unlimited access. A vendor has to protect its infrastructure. The honest tool for that is a limit, and the limit can be public.
Strava publishes its defaults in its developer documentation: 200 requests per 15 minutes and 2,000 per day for an application, with a lower read limit of 100 per 15 minutes and 1,000 per day. If an application goes over, it gets an HTTP 429 response. GitHub documents 60 requests per hour for unauthenticated calls and 5,000 per hour for an authenticated user. Garmin's developer page describes a personal tier where an individual gets an API key for their own data, and a separate business programme for companies.
None of these companies lost control by publishing numbers. They kept it. A key tells the vendor who is calling. A quota stops one caller from swamping the system. A polling limit decides how often a client may ask. Each protects the servers and each lets the data owner in without a conversation.
A gate protects the sales pipeline, which is a different thing. A "book a call" button does not slow a bad actor down. It slows down a studio like ours that wants to build a receiver and move on. In the AI era, a small team can build that receiver in days. The wait for a partner process is now longer than the build.
Cases where access was forced open or repriced
I would like to say gated incumbents always lose. I cannot back that with a source, so I will give you what I can verify.
In the UK, the Competition and Markets Authority required banks to implement Open Banking by early 2018, so that customers could share their information securely with other providers. By September 2025, Open Banking reported 15 million UK users, and in July 2026 it reported more than 100 billion API calls. Regulators did not wait to find out whether the banks would open up on their own.
In the US, the equivalent is less settled. The Consumer Financial Protection Bureau wrote a personal financial data rights rule under section 1033 of the Dodd-Frank Act. A court stayed its compliance dates on 29 October 2025, and the CFPB is reconsidering it. Forcing access open is contested ground, and I am not claiming otherwise. I have not checked developments after January 2026.
The third case runs the other way and shows what closed access costs people who depend on it. In April 2023, Twitter shut off free API access, and Engadget reported that apps and services were cut off, some without warning, including a social analytics service that shut down. If a vendor can reprice or remove access overnight, everyone built on top of it is exposed.
I expect the vendors that publish clear terms first to win the studios and clinics that build their own software, because we are the customers who notice.
What we want from vendors
Catalyst is moving its equipment to companies that respect the owner and give them the data they paid for. When we buy a device that produces client data, this is the list we hold it to:
- A documented API that covers the device we are buying, not only a premium model in the same range.
- Self-serve keys, so that the owner of the data can get one without a call.
- Published rate limits and polling limits, so that we know the rules before we write code.
- Webhooks or a scheduled export, so that a scan can arrive in our system by itself.
- Data that the client owns, with the right to take it with us if the client moves or we change supplier.
Frequently asked questions
Q. Who owns body composition scan data?
The person who was scanned. A studio or clinic holds it as custodian, and the device maker supplies the hardware and software. Catalyst treats the client as the owner, which is why we want the data to flow into reports the client can read.
Q. What is an API rate limit?
A rate limit caps how many requests an application can make in a set time, for example 200 per 15 minutes. It protects the vendor's servers from overload and tells developers the rules in advance. Strava and GitHub publish theirs.
Q. Can a body composition analyser send data straight into coaching software?
Yes, when the maker offers a documented API, a webhook or a scheduled export. Without one, the options are manual entry or a partner programme, both of which add time and cost.
Citations
Strava, "Rate Limiting", Strava Developers documentation. developers.strava.com/docs/rate-limits/ (read 5 November 2026).
GitHub, "Rate limits for the REST API", GitHub Docs. docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api (read 5 November 2026).
Garmin, "Garmin Connect Developer Program overview", Garmin Developer Portal. developer.garmin.com/gc-developer-program/overview/ (read 5 November 2026).
UK Competition and Markets Authority (9 August 2016), "CMA paves the way for Open Banking revolution", GOV.UK. gov.uk/government/news/cma-paves-the-way-for-open-banking-revolution (read 5 November 2026).
Open Banking Limited, news page, headlines of 1 September 2025 (15 million UK users) and 30 July 2026 (one billion payments and 100 billion API calls). openbanking.org.uk/news/ (read 5 November 2026).
Consumer Financial Protection Bureau, "Personal financial data rights", compliance resources, last modified 6 January 2026. consumerfinance.gov/compliance/compliance-resources/other-applicable-requirements/personal-financial-data-rights/ (read 5 November 2026).
Karissa Bell (6 April 2023), "Twitter shut off its free API and it's breaking a lot of apps", Engadget. engadget.com/twitter-shut-off-its-free-api-and-its-breaking-a-lot-of-apps-222011637.html (read 5 November 2026).
seca, "Body Composition Analysis", seca.com/en_ae/products/body-composition-analysis.html (read 5 November 2026).
seca (3 June 2025), "seca launches the seca TRU Alpha", seca.com news page, French-Belgian site. seca.com/fr_be/entreprise/actualites/details/article/seca-launches-the-seca-tru-alpha-always-the-first-choice-for-fitness-training-and-body-composition-analysis.html (read 5 November 2026).
seca, "We expand your options with ease" (EMR integration software), seca.com/products/emr-integration/software.html (read 5 November 2026).
PerfectGym Marketplace, "About Seca", marketplace.perfectgym.com/de/seca (read 5 November 2026).
Bosy-Westphal A, et al. (2017), "Quantification of whole-body and segmental skeletal muscle mass using phase-sensitive 8-electrode medical bioelectrical impedance devices", European Journal of Clinical Nutrition 71(9):1061-1067. pmc.ncbi.nlm.nih.gov/articles/PMC5589975/ (read 5 November 2026).
Jensen B, et al. (2019), Obesity Facts 12(3):307-315. pmc.ncbi.nlm.nih.gov/articles/PMC6696776 (read 5 November 2026).
InBody USA, "LB Web integration API key setup", lbwebfaq.inbodyusa.com/support/solutions/articles/69000848771-lb-web-integration-api-key-setup (read 5 November 2026). States the API is a paid service with an application form.
Mindbody, "Webhooks API documentation", Rate Limits section ("Your daily call limits are defined when you receive your API Key"). developers.mindbodyonline.com/WebhooksDocumentation (read 5 November 2026).
