The State of Fitness APIs 2026

Most surveys of this market are price lists, and every price list is wrong within a quarter. This one measures something else: access structure. Who is allowed to call the API, what stands between working code and a live product, and who has to already be paying someone before a single data point exists.

That layer moves slowly. A vendor can reprice twice a year without changing the fact that its API sits behind a partner review, or that its data only exists for people who bought the hardware. Structure is what you design against; price is what you negotiate later.

The dataset behind this report covers 25 APIs, SDKs and models across eight layers of a fitness stack. Every field is verified against vendor primary sources and published openly; downloads and the full method are at the end.

Key findings#

1. Free to call is not free to ship#

12 of the 25 items (48%) are free to call. That list: Fitbit, Oura, WHOOP, Polar, Apple HealthKit, Google Health Connect, USDA FoodData Central, Open Food Facts, wger, MediaPipe Pose Landmarker, TensorFlow MoveNet and Apple Vision body pose.

Now look at where the cost went. Fitbit, Oura, WHOOP, HealthKit and Health Connect are free and gated — someone else's review stands between your code and your launch. Fitbit, Oura and WHOOP are free and carry a user-side cost. wger is free and AGPL-3.0 copyleft, so the bill arrives as legal review; Open Food Facts is free and ODbL share-alike, which can force you to open a derived database.

What it means: "free" here describes one column of a spreadsheet that has four columns in it. Read it as "no per-request fee documented," then go find where the vendor took its cut instead. The cost planner keeps those columns separate; are fitness APIs free? works the same distinction from the buyer's side.

2. The approval-gate economy: 48% of the market makes you ask permission#

12 of the 25 items (48%) carry an approval gate — a review, declaration, cap or sales process you must clear before launch. All twelve, because the shapes differ enormously:

• WHOOP — a hard 10-member cap until production approval, and WHOOP requires developers to hold a membership themselves.
• Oura — a fresh app connects only a small number of users (reported around 10) until Oura's review, via the "Oura for Organizations" partner path.
• Garmin — Connect Developer Program partner approval; third parties report sign-ups paused at times (verify).
• Strava — Developer Program display rules: "Connect with Strava" branding and screenshots of every surface where Strava data appears.
• Fitbit — developer app registration; access to other users' intraday data is case-by-case (verify).
• Apple HealthKit — App Store review checks that your health usage-description strings match what you do.
• Google Health Connect — a Play Console health-data declaration and review before you can publish.
• Rook — several underlying providers still need your own developer credentials.
• Spike — sales-assisted onboarding with a dedicated implementation engineer from sandbox.
• Nutritionix — higher tiers gated through a Syndigo sales contact, not a self-serve checkout.
• KinesteX — a contact form and an issued API key; no self-serve signup.
• Sency — a free trial first (no credit card, per the vendor's site at our last check), then sales.

What it means: the currency here is calendar time, charged at a list price of zero. A partner review and a store declaration both sit on your critical path and neither appears in a budget. Start the gates before you need them — see Garmin API approval.

3. The membership wall: 5 items where your user pays before you do#

5 of the 25 items carry a documented user-side cost — something the end user must own or subscribe to before their data can flow at all. All five are direct wearable APIs:

That is five of the six items in the wearable-direct category. Polar Open AccessLink is the exception: no user-side cost and no approval gate are documented on our pages, making it the most self-serve first-party wearable API in the survey.

What it means: this is a market-size constraint wearing a cost-model costume. If your product needs WHOOP data, every prospective user is already a WHOOP subscriber — a ceiling that belongs in the business case, not the engineering budget. Wearable data APIs compared walks it per vendor.

4. Only 16% hides its terms completely — and it clusters in one layer#

4 of the 25 items (16%) are contact-sales-only: Garmin, Spike, Sency and KinesteX.

The concentration is telling. In the aggregator layer, Terra, Junction and Rook all bill on usage while Spike, the newest and broadest of them, routes through sales. In the AI motion layer, only QuickPose publishes a self-serve free tier; KinesteX and Sency both require a conversation before you can see terms. Garmin is the odd one out — the single first-party wearable API whose commercial terms are settled privately with approved partners.

Disclosure: KinesteX funds this site. It appears in the dataset on exactly the same terms as everyone else — classified contact-sales, approval gate recorded, no ranking, no accuracy claim, no exemption from the "could not verify pricing" treatment applied to its competitors. See KinesteX vs Sency.

What it means: where a vendor's value is a negotiated relationship rather than a metered endpoint, expect a quote with the lead time of an approval. Budget the conversation, not just the licence.

5. Every major wearable OAuth API rotates refresh tokens — all five of them#

This is the one place in the survey where an entire category behaves identically. Strava, WHOOP, Oura, Garmin and Fitbit all rotate the refresh token: the refresh response contains a new refresh token and the old one dies immediately.

The resulting outage is the most reproducible failure in fitness-API engineering. Refresh works once in testing, ships, then every user breaks with 400 invalid_grant on the second attempt, because the integration saved the new access token and dropped the new refresh token. Two aggravating factors recur: concurrent refreshes for one user race each other, and WHOOP only issues a refresh token when you request the offline scope.

What it means: treat every refresh token as single-use, persist the returned one atomically with the access token, and serialize refreshes per user. Full taxonomy in refresh token not working.

6. The pose layer is free and the layer above it is not — the value moved up the stack#

All 3 pose-estimation models in the survey are free: MediaPipe Pose Landmarker (BlazePose), TensorFlow MoveNet and Apple Vision body pose. The first two are Apache-2.0; Apple's runs inside its own SDK with no model file to ship. None carries an approval gate or a per-frame cost.

Directly above them, the 3 AI motion SDKs are all commercial: KinesteX and Sency behind sales, QuickPose on a free tier that runs out.

That gap is the finding. BlazePose returns 33 landmarks per frame; MoveNet returns 17 keypoints. Both stop there. Rep counting, per-exercise form rules, calibration, exercise content and cross-device tuning are not in the box, and they are not a one-time build — they recur as maintenance every time a new phone or a new exercise arrives.

What it means: the build-versus-buy question in AI fitness is not "can I get keypoints for free" (yes, trivially) but "who maintains everything between keypoints and a workout." Compare MediaPipe and MoveNet at the model layer, KinesteX vs MediaPipe across the gap, and fitness API vs build your own for scope.

7. Usage-based billing is rare, and it is mostly a way to buy back time#

Only 4 of the 25 items bill on usage: Terra, Junction and Rook among the aggregators, plus the LLM feature layer, which meters tokens with output priced above input.

Read that against finding 2. Terra and Junction carry no documented approval gate at all, and they exist precisely to broker provider authentication — the gates you would otherwise clear one wearable vendor at a time. The middle of the stack offers a real trade: pay a metered bill and skip a queue, or clear the queues yourself and pay nothing per call.

What it means: the aggregator decision is a schedule decision as much as a cost one. What no aggregator removes is anything attached to your own app rather than the data source — App Store review and the Play Console declaration survive regardless. Terra vs Vital/Junction and the aggregator overview cover what each broker actually brokers.

The market, layer by layer#

Per-vendor structure is broken out on Fitbit API pricing, aggregator pricing, nutrition API pricing and exercise database API pricing.

Methodology#

The sample. 25 items, chosen as the APIs, SDKs and models this site's own verified pages already cover in depth. That makes it coverage-driven, not a census: it is not exhaustive, implies nothing about market share, and skews toward vendors with English-language developer documentation. One row ("LLM API") stands for a feature category rather than a named vendor. The eight categories are ours, not an industry taxonomy.

Verification. Every non-judgement field was verified against vendor primary sources — developer documentation, public repositories, registries — during 2026, each backed by a sentence published on this site, with per-item provenance recorded in the cost model the dataset is generated from. Where the vendor's own material was absent or unreadable and only third-party reports existed, the claim is marked "reportedly" and carries a verify flag inline rather than being laundered into a fact.

Nulls are honest. A null means we could not verify it — never that the answer is zero, never a guess. Polar's empty user-side cost means no sentence on our pages documents one, not that none exists.

No prices, by design. There is not one monetary figure in this report or the dataset. Most serious tiers here are contact-sales, public figures move within quarters, and a stale number damages a citable source more than a missing one. This report is the editorial sibling of the cost planner, which likewise refuses to produce a total.

What we left out. Our engineering-effort estimate is judgement, not a vendor fact, so it stays in the planner where it is labelled as judgement and is excluded from the dataset. Counting gates is also binary and therefore lossy: an App Store review and a Garmin partner approval are both one gate here and are nothing alike. Read the per-item gate text, not just the count.

First-party disclosure. KinesteX funds this site. It is one of the 25 items and one of the 4 contact-sales items, recorded on the same terms as every competitor.

Licence and downloads. CC BY 4.0, version 2026.1, with a per-item source link on every row: fitness-apis-2026.json and fitness-apis-2026.csv.

Cite as: AIFitnessAPI, "The State of Fitness APIs 2026," aifitnessapi.com, updated 11 August 2026, https://aifitnessapi.com/state-of-fitness-apis-2026

What to watch into 2027#

Five things in this data look unstable. All of them are hedges, not predictions.

Fitbit is mid-migration to the Google Health API, and the successor's pricing model is not clearly public. Fitbit's free-to-call classification is the least stable cell in the table, and the thing to budget is a re-integration, not a fee. The Google Fit shutdown is the precedent for how this vendor retires things.

Strava's developer terms reportedly changed during 2026, with standard-tier developers said to need a paid subscription (verify). The consequential part is architectural, not commercial: an athlete's data may generally only be displayed back to that athlete, and using it to train AI or ML models is prohibited. If those restrictions spread, the binding constraint on this market shifts from price to permission — and no cost model would show it.

WHOOP has changed its membership structure recently. Because WHOOP requires both a developer membership and an active end-user membership, a restructuring moves two columns of this dataset at once.

Nutritionix's free tier is contested. Reports conflict on whether the open free tier still exists; if it is gone, that row looks closer to sales-gated — see Nutritionix vs Edamam.

MoveNet MultiPose has a licence gap. The MultiPose model card we read carried no licence line, while the single-person models are Apache-2.0. Until that resolves, "the pose layer is uniformly free" deserves an asterisk wherever multi-person tracking is involved. Confirm it independently before shipping commercially.

The next edition will re-verify every row and version the dataset rather than overwrite it, so a citation to 2026.1 keeps pointing at what 2026.1 said.