Fitbit API integration

No. That is the point of the integration. We hold the Google Health API registration, the client credentials and the redirect URI; you call POST /v1/connect with your own id for your own user and redirect their browser to the URL that comes back. There is no Fitbit secret in your environment, no callback route in your router, and no approval queue between you and your first connected athlete.

Two weeks free, then from 32.50 € a month billed annually — or 39 € a month with no year to commit to — for the whole API, every provider and every endpoint, with no per-athlete metering. Plans differ on one thing: how many of your users may connect a watch. Hacker is 250, for a project and its first users; Startup covers up to 5,000 of them; Scale up to 250,000; Enterprise removes the ceiling; and none of them meters calls, activities or endpoints. The usual price for a unified wearable API starts in the hundreds of dollars a month and charges again for each connected user, which is a pricing model that punishes exactly the thing you are trying to do. There is a 30-day money-back guarantee on any charge, and cancelling is a button in the Stripe billing portal; access ends when the period does.

You get push, not polling. When an athlete finishes a workout, Fitbit notifies us and we send you an activity.created delivery — sealed to your public key as a JWE and signed with a detached JWS you verify against our published JWKS. Latency is whatever Fitbit takes to process the upload from the watch, which is theirs to own and typically a matter of minutes. You never write a polling loop and never hold a rate-limit budget.

There is no API key anywhere in this, in either direction. You authenticate to us with an Ed25519 signature over the request itself — RFC 9421 HTTP Message Signatures — using a private key that never leaves your machine, so there is no bearer token sitting in a log line, a CI variable or a backup. And we never hand you the provider's own credentials either.

No. The Fitbit Web API is being shut down in September 2026, and this integration never touched it: it is built on the Google Health API, which is where Fitbit data lives from now on. For you nothing about that shows — you name fitbit in POST /v1/connect like any other provider — but it does mean a user who linked Fitbit to another product through the old API has to consent again here, because Google does not carry those tokens over.

Yes. A Pixel Watch syncs through the Fitbit app into the same Google Health account as a Fitbit tracker, so the integration reads both without telling them apart. The one thing to know is that the API does not say which device recorded a workout, so the device on an activity.created delivery reads “Fitbit”.

Yes. A night arrives as a wellness.created event with total sleep, the deep, light, REM and awake splits, and the per-stage timeline behind series_url, and it is updated in place when Google finishes processing it. Resting heart rate, HRV, breathing rate and SpO₂ arrive as their own daily records, each one number per day. What you do not get yet is steps or calories, and Google publishes no sleep score in this API.

Because TCX is what Google exports. The Google Health API has no FIT download, so the file behind a Fitbit activity is the TCX Google writes — GPS track, heart rate and laps as Google recorded them. Every other field on the delivery is in the same shape as a FIT-backed provider’s, so your handler does not branch.

Google lets a user untick permissions on the consent screen, and — unlike some providers — tells us which ones they kept, so the connection’s scope field is populated. Each kind of data is only read when its permission was granted: someone who allowed workouts but not sleep gets workouts and no sleep, and is never flagged as needing to reconnect for a choice they made. Someone who unticks everything comes back to your return URI as denied.