Whoop, Oura, Garmin & Fitbit APIs: Access Tiers, Limits and Costs

The question founders ask is "can you integrate Whoop?" The question that decides the project is "will Whoop let us, on what terms, and what will they actually give us?"

All four of these vendors have public developer documentation. None of them is a self-serve API in the sense that Stripe is. Each one has a gate between a working sandbox and a production integration serving your users, and the gates are different heights. Getting that wrong is how a two-week integration becomes a two-month wait.

This is the vendor-by-vendor picture: how access works, what the data looks like, where the rate limits bind, how far back you can read, and — the part nobody publishes — what each vendor will refuse you. We build these at $3,500 per platform; the wearable integrations page covers the commercial side. This page is the technical one.

The shape of the problem, before the details

All four follow the same architecture: the device syncs to a phone over Bluetooth, the phone syncs to the vendor's cloud, and you authenticate against the vendor's cloud with OAuth on behalf of the user. You never touch the device. Which means three things are true everywhere:

1. You cannot be fresher than the user's own app. If they haven't opened the Whoop or Oura app since waking, last night's sleep is still on the strap or the ring. No API call fixes that.
2. The user can revoke you at any time, from the vendor's own account settings, and you find out on the next failed call or a webhook you have to be listening for.
3. The proprietary scores are the product. Recovery, readiness, strain, Body Battery, sleep score — these are derived, vendor-owned numbers. You can usually display them. You generally cannot get the inputs, and the terms usually govern how you present them.

Whoop

Access. You register as a developer, create an app, and get client credentials. Whoop reviews applications before they serve real users at scale, and their terms constrain what kind of product may use the data. Start the paperwork the week you decide to build, not the week you're ready to ship.

Auth and scopes. Standard OAuth 2.0 authorization code flow. Scopes are granular and read-oriented — recovery, sleep, cycles, workouts, profile, body measurements — plus an offline scope you need in order to receive a refresh token. Request only what you'll use: a consent screen listing six scopes converts worse than one listing two, and reviewers notice scope requests you can't justify.

Data model. Whoop organizes around the physiological cycle rather than the calendar day — a cycle runs from wake to wake, not midnight to midnight. This is the single most important thing to understand before you design your schema. If you bucket Whoop data into calendar days you will disagree with the user's own Whoop app, and they will trust their app. Store the cycle boundaries Whoop gives you and present cycles as cycles.

Recovery is scored per cycle. Sleep is its own object with stage breakdowns. Workouts carry strain and heart-rate zone durations. Energy is reported in kilojoules rather than calories, which is an easy conversion and an easy bug.

Versioning. Whoop has migrated its API across major versions, with deprecation of the older one. Check which version your reference material describes before you copy anything — a surprising amount of blog content and AI-generated sample code targets the retired version.

What Whoop will not give you. Raw PPG or per-beat sensor data. The internals of the recovery and strain algorithms. Data for users who haven't authorized you. And their terms place limits on how you present and combine their scores — read them, because "we'll compute our own recovery score from Whoop inputs" is a plan that usually dies on contact with the agreement.

Oura

Access. Register a developer account and create an application. Oura offers personal access tokens, which are excellent for prototypes, internal tools and single-user analysis, and OAuth 2.0 for anything with real users. Production applications go through review.

The personal-token path is genuinely useful and underused: you can validate your entire data model against your own ring in an afternoon, before you spend anything on an OAuth flow.

Auth and scopes. OAuth 2.0 with scopes covering daily summaries, heart rate, workouts, sessions, SpO2 and personal info. Same advice: minimum viable scope set.

Data model. Oura's v2 API is the cleanest of the four. Endpoints are date-ranged, documents are well-shaped, and the daily summary objects (sleep, readiness, activity) map onto a product dashboard with very little translation. Of the six platforms we build, Oura is usually the fastest to a working integration.

Webhooks. Oura uses a subscription model: you create subscriptions programmatically, respond to a verification challenge, and renew them before they expire. That last part is the one teams miss. A subscription that quietly lapses looks exactly like a vendor outage, three weeks after launch, when nobody is looking at it. Put renewal on a scheduled job with alerting, not in a runbook.

Freshness. The ring has no radio to the internet. It syncs to the phone app over Bluetooth, and the phone app syncs to Oura. Overnight sleep typically appears after the user's first morning sync. Design your morning experience around "your data will appear once you open Oura," not around a guarantee.

What Oura will not give you. Raw PPG and temperature sensor streams. The readiness algorithm. And note that Oura's consumer subscription model matters commercially: some data availability is tied to the user's own subscription status, which is not something your integration can fix.

Garmin

Garmin is the one that surprises people, and it's worth planning around specifically.

Access is not self-serve. You apply to Garmin's developer program, describe your product and intended use, and sign an agreement before you get production credentials. There is a real evaluation step with a real human. Approval is not guaranteed, and it takes calendar time you cannot compress by writing code faster.

If your roadmap has "Garmin integration" in a specific sprint, start the application before the sprint. We've seen more Garmin projects blocked on paperwork than on engineering.

API products are separate. Garmin splits wellness/health data from detailed activity data across different API products with different terms. You need to know which one your feature requires before you apply, because applying for the wrong one costs you the cycle.

Push, not pull. Garmin's model is notification-driven: they push to your endpoint (or ping you to come fetch) when data is available. Polling is not the intended access pattern, and building your integration around a polling loop is both against the spirit of the platform and a good way to hit limits. Your webhook endpoint has to be up, fast, and idempotent from day one — you cannot fall back to "we'll just poll every 15 minutes."

Backfill is asynchronous. Garmin has an explicit historical backfill request: you ask for a date range, and the data arrives at your webhook over time rather than in a response body. Practically, this means onboarding a new user is not a synchronous operation. Build the "importing your history, we'll let you know" state properly, because you will need it.

What Garmin will not give you. Broad rights to redistribute or resell the data. Access without an agreement in force. And their terms constrain use cases — read them against your actual product, particularly if you plan to use the data for anything resembling clinical decision support or model training.

Why it's still worth it. Garmin's audience is the most data-serious cohort in consumer fitness, the activity data is the richest of the four, and those users churn hardest over sync errors. If you're building for runners, cyclists or triathletes, Garmin is not optional. If you're not, it may not be worth the paperwork yet — see the honest recommendation at the end.

Fitbit

Access. Register an app in the developer portal. Fitbit distinguishes application types — a personal type that gives you deeper access to your own account, and the types you use to serve other users. Understand which you've registered, because the personal type is the reason a prototype works and production doesn't.

The intraday gap. This is the Fitbit fact worth knowing before you scope anything. Daily summaries and coarse data are available to normal applications. Minute- and second-level intraday data — the granular heart rate and step series that make a real fitness product feel real — requires a separate request and approval from Fitbit. You can build a beautiful prototype against your own account with intraday access and discover at launch that your users get daily totals.

If your product's core experience depends on intraday resolution, resolve that access question first. Everything else about the integration is straightforward by comparison.

Rate limits. Fitbit enforces a per-user, per-hour request budget. The number is published and changes, so we won't quote it — the design principle is what matters: your rate limit scales with your user count, not with your server capacity. One user's budget cannot be spent on another user's data. Which means the failure mode is not "we're too big," it's "one power user with three years of history exhausts their own hourly budget during onboarding and their import stalls."

Subscriptions notify, they don't deliver. Fitbit's Subscriptions API tells you that something changed for a user and a collection. It does not send the data. You then make an API call to fetch it — which spends that user's rate budget. So a chatty webhook can cost you the very quota you need. Batch: collect notifications for a user over a short window, then make one consolidated fetch.

The Google account migration. Fitbit accounts have been migrating to Google accounts, which affects the authentication surface over time. If you're building now, check the current state of that migration and what it means for your OAuth flow and for existing tokens.

What Fitbit will not give you. Intraday data without approval. Raw sensor streams. Unlimited request volume per user.

Designing so rate limits never bind

Every one of these vendors will rate limit you. None of them should ever be your production incident, if you build these five things:

1. Webhook-first, fetch-on-demand. Never poll on a fixed interval for all users. Let the vendor tell you when there's something to get.
2. Per-user token buckets, not a global one. Because the limits are per-user. A global limiter both over-restricts your quiet users and fails to protect your heavy ones.
3. Jitter every schedule. If you do run a periodic reconciliation, do not run it for all users at 03:00. Spread it deterministically by user ID hash. A thundering herd against a vendor API is a self-inflicted outage.
4. Exponential backoff with respect for Retry-After. And a circuit breaker per vendor, so one vendor's bad afternoon doesn't consume your worker pool.
5. A separate, slower queue for backfill. Historical import competes with live sync for the same budget. Give it its own lane and its own lower priority, and tell the user it's running.

Do these and rate limits become a graph you look at, not a page you get woken by.

Historical backfill, per vendor

The user expectation is "show me my history." The reality is four different answers:

• Whoop and Oura: paginated or date-ranged collection endpoints. Straightforward, but a multi-year import is many requests against a per-user budget. Import recent history synchronously, older history in the background.
• Garmin: an explicit asynchronous backfill request. Data arrives at your webhook over time. Onboarding is not synchronous.
• Fitbit: date-range endpoints, hard-capped by the per-user hourly budget. A long history import is a multi-hour job for that user, by design.

The scoping decision that saves the most money: decide the minimum history your product needs. Thirty days of recovery data delivers most of the product value of three years, at a fraction of the engineering. Import the rest lazily, for the users who ask.

What this costs, and which ones to skip

Each of these is its own project. Different auth, different data model, different webhook contract, different paperwork, different edge cases. That's why we price wearable integrations at $3,500 per platform rather than one blended number, and why the honest timeline is two to four weeks per platform — most of which is not API wiring. It's deduplication rules, unit normalization, timezone handling and QA on physical hardware. The full breakdown is in wearable integration cost and timeline, and everything else we publish a price for is on the pricing page.

Now the unprofitable part.

Most products building their first wearable feature should not start with any of these four. They should start with HealthKit or Health Connect, because that's where the majority of users already are, and because Whoop, Oura and Garmin users' data often lands in HealthKit anyway via the vendors' own apps. It's lower fidelity and lower freshness, and for a first version it is frequently enough to learn whether anyone uses the feature.

Build Whoop or Oura directly when recovery is your product — a coaching platform that programs around readiness genuinely needs the score, at the cycle boundaries the vendor defines, with the freshness the vendor's cloud provides. HealthKit will not give you that.

Build Garmin when your audience is endurance athletes. Not before. The paperwork and the activity-file handling are real costs, and a general wellness app rarely earns them back.

Build Fitbit when you're selling into corporate wellness, where the installed base is real and the buyer often specifies it. For a consumer fitness app in 2026, Fitbit is usually not the first integration.

And consider an aggregator instead of three of the four. If you need Whoop plus Oura plus Garmin plus Polar plus Suunto, the per-user monthly fee for an aggregator is very likely cheaper than four integrations plus four sets of vendor paperwork plus the ongoing support burden. We'll tell you when that's the case, even though it's the smaller project for us.

If you want that decision made with your own analytics rather than a guess, that's what a planning engagement is for — talk to us, or read how we work with founders on health-tech startups.

Frequently asked questions

Do I need Whoop's permission to build a Whoop integration?

You need a registered developer application and you're bound by their developer terms, and production use at scale goes through their review. It is closer to self-serve than Garmin and less open than a typical SaaS API. Register early and read the terms against your actual product, particularly if you plan to transform or re-score their data.

Is the Garmin Health API free?

Garmin's developer program involves an application and a signed agreement rather than a public price list, and terms depend on your use case and volume. Treat commercial terms as something to establish during the application, not something to assume. Budget calendar time for it regardless of cost.

Can I get real-time heart rate from Oura or Whoop?

Not in the sense of a live stream. Both are cloud APIs fed by a phone sync, so your freshness is bounded by when the user's own app last synced the device. If you need live heart rate during a session, you need an on-device path — Bluetooth directly to a chest strap, or an Apple Watch workout session — not a vendor cloud API.

Why does my Fitbit integration return daily totals instead of minute data?

Almost certainly because you're not approved for intraday access. Intraday resolution requires a separate request to Fitbit, and personal-type applications can access it for their own account, which is why prototypes work and production doesn't. Resolve this before you design any feature that depends on granular data.

How long does a Whoop or Oura integration take?

Two to four weeks per platform is our published range, and the API work is the fast part of it. The calendar goes into merge rules when the user has more than one device, unit and timezone normalization, permission and revocation states, backfill behavior, and testing against real hardware rather than sandbox fixtures.

Should we use an aggregator like Terra instead?

If you need four or more vendors, probably yes. If you need one or two, an aggregator is a recurring per-user fee for work you'd do once. The dividing line, plus what aggregators genuinely cannot do for you, is covered in HealthKit vs Health Connect vs Terra.

Can wearable data go into a HIPAA-regulated system?

It can, and then every vendor and aggregator in the path is a processor you need to evaluate, with a BAA where one is required. Not all of them will sign. Settle that before you build. Zee Palm builds HIPAA-aware systems and maps those boundaries during planning — we don't issue certifications or legal sign-off.